I just committed some changes into 0.9.0 auth* modules - basically it's just a backport from the development branch. Mainly to solve some issues regarding the RPID handling (there were quite some reports about RPID problems in 0.9.0), which was one of the last drawbacks before 0.9.0 release.
Interface changes:
auth_db: param "load_credentials": list of '|' separated columns to be load from subscriber table at auth time. The values for each column is loaded in a corresponding AVP (string type) with same name as the column; Default value is "rpid". Empty value "" disable this feature.
auth: param "rpid_avp": avp name (string) which carry the RPID value - must be synchronized with auth_db if RPID is fetched from DB. Default value is "rpid".
Please all 0.9.0 users, give it a try a report any potential problems.
bogdan
Hi all,
I've tested the new code but now the problem is worst after the change....the rpid HF in outgoing INVITE is ever wrong (missing some digits) and the gateway is unable to understood the RPID HF....in my ser.cfg I've only this line related to RPID handling (before t_relay()):
append_rpid_hf("<", ">;party=calling;id-type=subscriber;screen=yes;privacy=off");
Here a ngrepped log where the actors are:
A.B.C.D: IP_address_SER E.F.G.H: calling_ATA K.X.Y.Z: gateway_Cisco
U E.F.G.H:5060 -> A.B.C.D:5060
INVITE sip:05751944945@my.sip.domain SIP/2.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Proxy-Authorization: Digest username="0662293701",realm="my.sip.domain",nonce="4264fd7095fad869d82db77f8760f99a194081be",uri="sip:05751944945@my.sip.domain",response="af95e0eb4634f403312d1543713af228",cnonce="1baf129b",qop="auth",nc="00000021".
Max-Forwards: 70.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U A.B.C.D:5060 -> E.F.G.H:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Date: Tue, 19 Apr 2005 12:40:36 GMT+01:00.
Server: SPSexp (0.9.1 (i386/linux)).
Content-Length: 0.
Warning: 392 A.B.C.D:5060 "Noisy feedback tells: pid=2511 req_src_ip=E.F.G.H req_src_port=5060 in_uri=sip:05751944945@my.sip.domainout_uri=sip:49105751944945@K.X.Y.Z:5060 via_cnt==1".
.
#
U A.B.C.D:5060 -> K.X.Y.Z:5060
INVITE sip:49105751944945@K.X.Y.Z:5060 SIP/2.0.
Record-Route: sip:A.B.C.D;ftag=ttf2004-2027030565-4e3430a3-1528472774;lr=on.
Via: SIP/2.0/UDP A.B.C.D;branch=z9hG4bKfc13.4b9ec207.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Max-Forwards: 16.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
P-hint: Call_From_Postpaid_User.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
Any suggestions?
Regards,
Verbal
----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "SER developer mailing list" serdev@lists.iptel.org Cc: "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 1:12 PM Subject: [Serdev] Auth* changes
I just committed some changes into 0.9.0 auth* modules - basically it's just a backport from the development branch. Mainly to solve some issues regarding the RPID handling (there were quite some reports about RPID problems in 0.9.0), which was one of the last drawbacks before 0.9.0 release.
Interface changes:
auth_db: param "load_credentials": list of '|' separated columns to be load from subscriber table at auth time. The values for each column is loaded in a corresponding AVP (string type) with same name as the column; Default value is "rpid". Empty value "" disable this feature.
auth: param "rpid_avp": avp name (string) which carry the RPID value - must be synchronized with auth_db if RPID is fetched from DB. Default value is "rpid".
Please all 0.9.0 users, give it a try a report any potential problems.
bogdan
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
probably you are referring to this header:
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
the URI part is loaded from DB via auth_db as an AVP. So please first check if in the DB value is correct and then, after authentication sequence, via avp_print() (avpops module) verify the value of the "rpid" AVP. See where the URI become bogus.
bogdan
Francesco Bottà wrote:
Hi all,
I've tested the new code but now the problem is worst after the change....the rpid HF in outgoing INVITE is ever wrong (missing some digits) and the gateway is unable to understood the RPID HF....in my ser.cfg I've only this line related to RPID handling (before t_relay()):
append_rpid_hf("<", ">;party=calling;id-type=subscriber;screen=yes;privacy=off");
Here a ngrepped log where the actors are:
A.B.C.D: IP_address_SER E.F.G.H: calling_ATA K.X.Y.Z: gateway_Cisco
U E.F.G.H:5060 -> A.B.C.D:5060
INVITE sip:05751944945@my.sip.domain SIP/2.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Proxy-Authorization: Digest username="0662293701",realm="my.sip.domain",nonce="4264fd7095fad869d82db77f8760f99a194081be",uri="sip:05751944945@my.sip.domain",response="af95e0eb4634f403312d1543713af228",cnonce="1baf129b",qop="auth",nc="00000021".
Max-Forwards: 70.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U A.B.C.D:5060 -> E.F.G.H:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Date: Tue, 19 Apr 2005 12:40:36 GMT+01:00.
Server: SPSexp (0.9.1 (i386/linux)).
Content-Length: 0.
Warning: 392 A.B.C.D:5060 "Noisy feedback tells: pid=2511 req_src_ip=E.F.G.H req_src_port=5060 in_uri=sip:05751944945@my.sip.domainout_uri=sip:49105751944945@K.X.Y.Z:5060 via_cnt==1".
.
#
U A.B.C.D:5060 -> K.X.Y.Z:5060
INVITE sip:49105751944945@K.X.Y.Z:5060 SIP/2.0.
Record-Route: sip:A.B.C.D;ftag=ttf2004-2027030565-4e3430a3-1528472774;lr=on.
Via: SIP/2.0/UDP A.B.C.D;branch=z9hG4bKfc13.4b9ec207.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Max-Forwards: 16.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
P-hint: Call_From_Postpaid_User.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
Any suggestions?
Regards,
Verbal
----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "SER developer mailing list" serdev@lists.iptel.org Cc: "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 1:12 PM Subject: [Serdev] Auth* changes
I just committed some changes into 0.9.0 auth* modules - basically it's just a backport from the development branch. Mainly to solve some issues regarding the RPID handling (there were quite some reports about RPID problems in 0.9.0), which was one of the last drawbacks before 0.9.0 release.
Interface changes:
auth_db: param "load_credentials": list of '|' separated columns to be load from subscriber table at auth time. The values for each column is loaded in a corresponding AVP (string type) with same name as the column; Default value is "rpid". Empty value "" disable this feature.
auth: param "rpid_avp": avp name (string) which carry the RPID value - must be synchronized with auth_db if RPID is fetched from DB. Default value is "rpid".
Please all 0.9.0 users, give it a try a report any potential problems.
bogdan
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Hi Bogdan,
in attach the log with avp_print() submitted just after the authentication challange and just before the t_relay() function....to me seems that something is overriding the value of rpid_avp in memory....
Any suggestions?
Many thanx
Verbal ----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "Francesco Bottà " francesco.botta@eutelia.it Cc: "SER developer mailing list" serdev@lists.iptel.org; "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 3:14 PM Subject: Re: [Serdev] Auth* changes
probably you are referring to this header:
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
the URI part is loaded from DB via auth_db as an AVP. So please first check if in the DB value is correct and then, after authentication sequence, via avp_print() (avpops module) verify the value of the "rpid" AVP. See where the URI become bogus.
bogdan
Francesco Bottà wrote:
Hi all,
I've tested the new code but now the problem is worst after the change....the rpid HF in outgoing INVITE is ever wrong (missing some digits) and the gateway is unable to understood the RPID HF....in my ser.cfg I've only this line related to RPID handling (before t_relay()):
append_rpid_hf("<", ">;party=calling;id-type=subscriber;screen=yes;privacy=off");
Here a ngrepped log where the actors are:
A.B.C.D: IP_address_SER E.F.G.H: calling_ATA K.X.Y.Z: gateway_Cisco
U E.F.G.H:5060 -> A.B.C.D:5060
INVITE sip:05751944945@my.sip.domain SIP/2.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Proxy-Authorization: Digest username="0662293701",realm="my.sip.domain",nonce="4264fd7095fad869d82db77f8760f99a194081be",uri="sip:05751944945@my.sip.domain",response="af95e0eb4634f403312d1543713af228",cnonce="1baf129b",qop="auth",nc="00000021".
Max-Forwards: 70.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U A.B.C.D:5060 -> E.F.G.H:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Date: Tue, 19 Apr 2005 12:40:36 GMT+01:00.
Server: SPSexp (0.9.1 (i386/linux)).
Content-Length: 0.
Warning: 392 A.B.C.D:5060 "Noisy feedback tells: pid=2511 req_src_ip=E.F.G.H req_src_port=5060 in_uri=sip:05751944945@my.sip.domainout_uri=sip:49105751944945@K.X.Y.Z:5060 via_cnt==1".
.
#
U A.B.C.D:5060 -> K.X.Y.Z:5060
INVITE sip:49105751944945@K.X.Y.Z:5060 SIP/2.0.
Record-Route: sip:A.B.C.D;ftag=ttf2004-2027030565-4e3430a3-1528472774;lr=on.
Via: SIP/2.0/UDP A.B.C.D;branch=z9hG4bKfc13.4b9ec207.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Max-Forwards: 16.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
P-hint: Call_From_Postpaid_User.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
Any suggestions?
Regards,
Verbal
----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "SER developer mailing list" serdev@lists.iptel.org Cc: "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 1:12 PM Subject: [Serdev] Auth* changes
I just committed some changes into 0.9.0 auth* modules - basically it's just a backport from the development branch. Mainly to solve some issues regarding the RPID handling (there were quite some reports about RPID problems in 0.9.0), which was one of the last drawbacks before 0.9.0 release.
Interface changes:
auth_db: param "load_credentials": list of '|' separated columns to be load from subscriber table at auth time. The values for each column is loaded in a corresponding AVP (string type) with same name as the column; Default value is "rpid". Empty value "" disable this feature.
auth: param "rpid_avp": avp name (string) which carry the RPID value - must be synchronized with auth_db if RPID is fetched from DB. Default value is "rpid".
Please all 0.9.0 users, give it a try a report any potential problems.
bogdan
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
as the log shows, the RPID is loaded correctly:
5(4865) generate_avps: set string AVP 'rpid = sip:0662293701@my.sip.domain'
and at the first avp_print() I see everything ok:
5(4865) DEBUG:avpops:print_avp: p=0x4053eab8, flags=3
5(4865) DEBUG: name=<rpid>
5(4865) DEBUG: val_str=sip:0662293701@my.sip.domain
The problem appears after some further processing (mostly regarding LCR):
5(4865) DEBUG:avpops:print_avp: p=0x4053eb18, flags=2
5(4865) DEBUG: id=<1400>
5(4865) DEBUG: val_str=<>^ÑÄ>
5(4865) DEBUG:avpops:print_avp: p=0x4053eab8, flags=3
5(4865) DEBUG: name=<rpid>
5(4865) DEBUG: val_str=sip:06
as you can see the AVP information look corrupted. try to remove the lcr stuff and see if your problem persists.
bogdan
Francesco Bottà wrote:
Hi Bogdan,
in attach the log with avp_print() submitted just after the authentication challange and just before the t_relay() function....to me seems that something is overriding the value of rpid_avp in memory....
Any suggestions?
Many thanx
Verbal ----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "Francesco Bottà " francesco.botta@eutelia.it Cc: "SER developer mailing list" serdev@lists.iptel.org; "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 3:14 PM Subject: Re: [Serdev] Auth* changes
probably you are referring to this header:
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
the URI part is loaded from DB via auth_db as an AVP. So please first check if in the DB value is correct and then, after authentication sequence, via avp_print() (avpops module) verify the value of the "rpid" AVP. See where the URI become bogus.
bogdan
Francesco Bottà wrote:
Hi all,
I've tested the new code but now the problem is worst after the change....the rpid HF in outgoing INVITE is ever wrong (missing some digits) and the gateway is unable to understood the RPID HF....in my ser.cfg I've only this line related to RPID handling (before t_relay()):
append_rpid_hf("<", ">;party=calling;id-type=subscriber;screen=yes;privacy=off");
Here a ngrepped log where the actors are:
A.B.C.D: IP_address_SER E.F.G.H: calling_ATA K.X.Y.Z: gateway_Cisco
U E.F.G.H:5060 -> A.B.C.D:5060
INVITE sip:05751944945@my.sip.domain SIP/2.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Proxy-Authorization: Digest username="0662293701",realm="my.sip.domain",nonce="4264fd7095fad869d82db77f8760f99a194081be",uri="sip:05751944945@my.sip.domain",response="af95e0eb4634f403312d1543713af228",cnonce="1baf129b",qop="auth",nc="00000021".
Max-Forwards: 70.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U A.B.C.D:5060 -> E.F.G.H:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Date: Tue, 19 Apr 2005 12:40:36 GMT+01:00.
Server: SPSexp (0.9.1 (i386/linux)).
Content-Length: 0.
Warning: 392 A.B.C.D:5060 "Noisy feedback tells: pid=2511 req_src_ip=E.F.G.H req_src_port=5060 in_uri=sip:05751944945@my.sip.domainout_uri=sip:49105751944945@K.X.Y.Z:5060 via_cnt==1".
.
#
U A.B.C.D:5060 -> K.X.Y.Z:5060
INVITE sip:49105751944945@K.X.Y.Z:5060 SIP/2.0.
Record-Route: sip:A.B.C.D;ftag=ttf2004-2027030565-4e3430a3-1528472774;lr=on.
Via: SIP/2.0/UDP A.B.C.D;branch=z9hG4bKfc13.4b9ec207.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Max-Forwards: 16.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
P-hint: Call_From_Postpaid_User.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
Any suggestions?
Regards,
Verbal
----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "SER developer mailing list" serdev@lists.iptel.org Cc: "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 1:12 PM Subject: [Serdev] Auth* changes
I just committed some changes into 0.9.0 auth* modules - basically it's just a backport from the development branch. Mainly to solve some issues regarding the RPID handling (there were quite some reports about RPID problems in 0.9.0), which was one of the last drawbacks before 0.9.0 release.
Interface changes:
auth_db: param "load_credentials": list of '|' separated columns to be load
from subscriber table at auth time. The values for each column is loaded
in a corresponding AVP (string type) with same name as the column; Default value is "rpid". Empty value "" disable this feature.
auth: param "rpid_avp": avp name (string) which carry the RPID value - must be synchronized with auth_db if RPID is fetched from DB. Default value is "rpid".
Please all 0.9.0 users, give it a try a report any potential problems.
bogdan
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Hi Bogdan,
I've recompiled the code excluding LCR module, and now all working fine....the RPID HF in the INVITE forwarded from SER to GW is now correct:
Remote-Party-ID: sip:0662293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
What's wrong with the LCR module that overrides the rpid_avp value?
My LCR module is patched with the gw capability introduced by A. Granig...but before your changes applyed today all was working fine....in what way the changes in the auth and auth_db module are correlated with lcr module?
Many thanx...as usually..
Verbal
----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "Francesco Bottà " francesco.botta@eutelia.it Cc: "SER developer mailing list" serdev@lists.iptel.org; "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 5:26 PM Subject: Re: [Serdev] Auth* changes
as the log shows, the RPID is loaded correctly:
5(4865) generate_avps: set string AVP 'rpid = sip:0662293701@my.sip.domain'
and at the first avp_print() I see everything ok:
5(4865) DEBUG:avpops:print_avp: p=0x4053eab8, flags=3
5(4865) DEBUG: name=<rpid>
5(4865) DEBUG: val_str=sip:0662293701@my.sip.domain
The problem appears after some further processing (mostly regarding LCR):
5(4865) DEBUG:avpops:print_avp: p=0x4053eb18, flags=2
5(4865) DEBUG: id=<1400>
5(4865) DEBUG: val_str=<>^ÑÄ>
5(4865) DEBUG:avpops:print_avp: p=0x4053eab8, flags=3
5(4865) DEBUG: name=<rpid>
5(4865) DEBUG: val_str=sip:06
as you can see the AVP information look corrupted. try to remove the lcr stuff and see if your problem persists.
bogdan
Francesco Bottà wrote:
Hi Bogdan,
in attach the log with avp_print() submitted just after the authentication challange and just before the t_relay() function....to me seems that something is overriding the value of rpid_avp in memory....
Any suggestions?
Many thanx
Verbal ----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "Francesco Bottà " francesco.botta@eutelia.it Cc: "SER developer mailing list" serdev@lists.iptel.org; "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 3:14 PM Subject: Re: [Serdev] Auth* changes
probably you are referring to this header:
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
the URI part is loaded from DB via auth_db as an AVP. So please first check if in the DB value is correct and then, after authentication sequence, via avp_print() (avpops module) verify the value of the "rpid" AVP. See where the URI become bogus.
bogdan
Francesco Bottà wrote:
Hi all,
I've tested the new code but now the problem is worst after the change....the rpid HF in outgoing INVITE is ever wrong (missing some digits) and the gateway is unable to understood the RPID HF....in my ser.cfg I've only this line related to RPID handling (before t_relay()):
append_rpid_hf("<", ">;party=calling;id-type=subscriber;screen=yes;privacy=off");
Here a ngrepped log where the actors are:
A.B.C.D: IP_address_SER E.F.G.H: calling_ATA K.X.Y.Z: gateway_Cisco
U E.F.G.H:5060 -> A.B.C.D:5060
INVITE sip:05751944945@my.sip.domain SIP/2.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Proxy-Authorization: Digest username="0662293701",realm="my.sip.domain",nonce="4264fd7095fad869d82db77f8760f99a194081be",uri="sip:05751944945@my.sip.domain",response="af95e0eb4634f403312d1543713af228",cnonce="1baf129b",qop="auth",nc="00000021".
Max-Forwards: 70.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
#
U A.B.C.D:5060 -> E.F.G.H:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Date: Tue, 19 Apr 2005 12:40:36 GMT+01:00.
Server: SPSexp (0.9.1 (i386/linux)).
Content-Length: 0.
Warning: 392 A.B.C.D:5060 "Noisy feedback tells: pid=2511 req_src_ip=E.F.G.H req_src_port=5060 in_uri=sip:05751944945@my.sip.domainout_uri=sip:49105751944945@K.X.Y.Z:5060 via_cnt==1".
.
#
U A.B.C.D:5060 -> K.X.Y.Z:5060
INVITE sip:49105751944945@K.X.Y.Z:5060 SIP/2.0.
Record-Route: sip:A.B.C.D;ftag=ttf2004-2027030565-4e3430a3-1528472774;lr=on.
Via: SIP/2.0/UDP A.B.C.D;branch=z9hG4bKfc13.4b9ec207.0.
Via: SIP/2.0/UDP E.F.G.H:5060;branch=z9hG4bK72757e5898649d225fbab82c5b090092.
Max-Forwards: 16.
From: "0662293701"sip:0662293701@my.sip.domain;tag=ttf2004-2027030565-4e3430a3-1528472774.
To: sip:05751944945@my.sip.domain.
Contact: "0662293701"sip:0662293701@E.F.G.H:5060.
Call-ID: 4F6F-4259-8014290-8CB71C2226CD-0027@E.F.G.H.
CSeq: 33 INVITE.
Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER.
Content-Disposition: session.
Content-Encoding: identity.
Content-Language: en.
Content-Length: 223.
Content-Type: application/sdp.
Expires: 180.
Supported: replaces.
User-Agent: ttf2004.
Remote-Party-ID: sip:06..293701@my.sip.domain;party=calling;id-type=subscriber;screen=yes;privacy=off.
P-hint: Call_From_Postpaid_User.
.
v=0.
o=0662293701 2489050800 1 IN IP4 E.F.G.H.
s=Session SDP.
c=IN IP4 E.F.G.H.
t=0 0.
m=audio 5002 RTP/AVP 8 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
Any suggestions?
Regards,
Verbal
----- Original Message ----- From: "Bogdan-Andrei Iancu" bogdan@voice-system.ro To: "SER developer mailing list" serdev@lists.iptel.org Cc: "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 1:12 PM Subject: [Serdev] Auth* changes
I just committed some changes into 0.9.0 auth* modules - basically it's just a backport from the development branch. Mainly to solve some issues regarding the RPID handling (there were quite some reports about RPID problems in 0.9.0), which was one of the last drawbacks before 0.9.0 release.
Interface changes:
auth_db: param "load_credentials": list of '|' separated columns to be load
from subscriber table at auth time. The values for each column is loaded
in a corresponding AVP (string type) with same name as the column; Default value is "rpid". Empty value "" disable this feature.
auth: param "rpid_avp": avp name (string) which carry the RPID value - must be synchronized with auth_db if RPID is fetched from DB. Default value is "rpid".
Please all 0.9.0 users, give it a try a report any potential problems.
bogdan
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Hi Juha,
the problem is not in your module lcr (backported for rel 0.9.0)....I've recompiled your lcr module without patch (lcr.diff) that introduced gw_cap (prefix) features and all still working fine....at this point the problem seems to be related with the lcr.diff patch committed from A. Granig that in some way overrides the rpid_avp values....
Have you ever tryed the patch introduced by A. Granig?
Any hints?
Regards,
Verbal ----- Original Message ----- From: "Juha Heinanen" jh@tutpro.com To: "Francesco Bottà " francesco.botta@eutelia.it Cc: "Bogdan-Andrei Iancu" bogdan@voice-system.ro; "SER developer mailing list" serdev@lists.iptel.org; "serusers" serusers@lists.iptel.org Sent: Tuesday, April 19, 2005 6:08 PM Subject: Re: [Serdev] Auth* changes
Francesco Bottà writes:
What's wrong with the LCR module that overrides the rpid_avp value?
there may be a bug in lcr module. i'm looking into it.
-- juha
Francesco Bottà writes:
the problem is not in your module lcr (backported for rel 0.9.0)....I've recompiled your lcr module without patch (lcr.diff) that introduced gw_cap (prefix) features and all still working fine....at this point the problem seems to be related with the lcr.diff patch committed from A. Granig that in some way overrides the rpid_avp values....
ok. i read through lcr code anyway and found one bug, but that was related to a debug statement and didn't write anything anywhere. i also did some cleanups and introduced one new feature:
- if request has rpid header, "from uri" is taken from it instead of from header.
hope that suits everybody. i'll commit my changed after testing and will also make a new rel_0_9_0 backport.
Have you ever tryed the patch introduced by A. Granig?
no, i haven't.
-- juha
- if request has rpid header, "from uri" is taken from it instead of
from header.
with "from uri" have you in mind the rules that apply to lcr algorithm, not change the from HF in the sending INVITE??
My thought is correct or I'm misunderstanding somenthing??
So, If I call the load_gw and next_gw functions before append_rpid_hf_p (without any other RPID HF present), nothing should change with your module..
Many thanx
Verbal ----- Original Message ----- From: "Juha Heinanen" jh@tutpro.com To: "Francesco Bottà " francesco.botta@eutelia.it Cc: "Bogdan-Andrei Iancu" bogdan@voice-system.ro; "SER developer mailing list" serdev@lists.iptel.org; "serusers" serusers@lists.iptel.org; "Andreas Granig" andreas.granig@inode.info Sent: Tuesday, April 19, 2005 7:01 PM Subject: Re: [Serdev] Auth* changes
Francesco Bottà writes:
the problem is not in your module lcr (backported for rel 0.9.0)....I've recompiled your lcr module without patch (lcr.diff) that introduced gw_cap (prefix) features and all still working fine....at this point the problem seems to be related with the lcr.diff patch committed from A. Granig that in some way overrides the rpid_avp values....
ok. i read through lcr code anyway and found one bug, but that was related to a debug statement and didn't write anything anywhere. i also did some cleanups and introduced one new feature:
- if request has rpid header, "from uri" is taken from it instead of from header.
hope that suits everybody. i'll commit my changed after testing and will also make a new rel_0_9_0 backport.
Have you ever tryed the patch introduced by A. Granig?
no, i haven't.
-- juha
Francesco Bottà writes:
with "from uri" have you in mind the rules that apply to lcr algorithm, not change the from HF in the sending INVITE??
if incoming request has RPID HF, then "From URI" is taken from it instead of From HF. no HFs are changed.
So, If I call the load_gw and next_gw functions before append_rpid_hf_p (without any other RPID HF present), nothing should change with your module..
that is right.
-- juha
Bogdan-Andrei Iancu writes:
param "rpid_avp": avp name (string) which carry the RPID value -must be synchronized with auth_db if RPID is fetched from DB. Default value is "rpid".
i would prefer default value "caller_rpid", because the idea is that does_uri_exist would similarly set callee attributes and thus there will be need to tell them apart.
Please all 0.9.0 users, give it a try a report any potential problems.
i tried it with lcr module and didn't have any problems.
-- juha
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
param "rpid_avp": avp name (string) which carry the RPID value -must be synchronized with auth_db if RPID is fetched from DB. Default value is "rpid".
i would prefer default value "caller_rpid", because the idea is that does_uri_exist would similarly set callee attributes and thus there will be need to tell them apart.
caller|callee_rpid notation makes no sense since you don't have any rpid for callee, right? Plus that you restrict the AVP only to AVP name - I plan to have in dev branch the option to set an AVP id for rpid also. if you want for any reasons to used it with different name, use avp_copy() from avpops (only on dev branch)
Please all 0.9.0 users, give it a try a report any potential problems.
i tried it with lcr module and didn't have any problems.
that's good
bogdan
Bogdan-Andrei Iancu writes:
caller|callee_rpid notation makes no sense since you don't have any rpid for callee, right?
sure callee uri can also have rpid associated with it.
Plus that you restrict the AVP only to AVP name - I plan to have in dev branch the option to set an AVP id for rpid also.
that is the other issue i forgot to mention. i think it should be possible already in rel_0_9_0 to give rpid avp an id instead of name.
since this rpid change (which was not a bug fix) was backported to rel_0_9_0, it should be done properly, i.e., it should use avp spec like tm avp params do. i just counted that in my script rpid avp may get used five times during processing of one invite and i'm worried about the performance impact of string rpid avp name.
so since the backport was against of the rules, i suggest that the change is reversed or done properly that also allows an integer as rpid avp name.
-- juha
Hello,
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
caller|callee_rpid notation makes no sense since you don't have any rpid for callee, right?
sure callee uri can also have rpid associated with it.
Plus that you restrict the AVP only to AVP name - I plan to have in dev branch the option to set an AVP id for rpid also.
that is the other issue i forgot to mention. i think it should be possible already in rel_0_9_0 to give rpid avp an id instead of name.
since this rpid change (which was not a bug fix) was backported to rel_0_9_0, it should be done properly, i.e., it should use avp spec like tm avp params do. i just counted that in my script rpid avp may get used five times during processing of one invite and i'm worried about the performance impact of string rpid avp name.
so since the backport was against of the rules, i suggest that the change is reversed or done properly that also allows an integer as rpid avp name.
I, from a user's point of view, am against the reversal of this backport. I like the functionality in 0_9_0 alot and think it is very useful. However, Juha's point regarding performance remains valid.
With best regards, Martin Koenig
Martin Koenig writes:
I, from a user's point of view, am against the reversal of this backport. I like the functionality in 0_9_0 alot and think it is very useful. However, Juha's point regarding performance remains valid.
there are lots of things i like in unstable branch and which i would like to get officially committed to rel_0_9_0, but haven't proposed or done any, because i thought that as advertized, rel_0_9_0 is a frozen branch, where only bug fixes were allowed to be committed.
if the rules have changed, perhaps i'm allowed to commit lcr module, for example, to rel_0_9_0? either we re-open the branch or we don't.
the auth rpid changes that were committed yesterday, will force me to change in MANY rel_0_9_0 proxies the way radius returns caller rpid, i.e., the chance is not backwards compatible.
is there anyone in charge here?
-- juha
Juha,
indeed rel_0_9_0 is and will stay frozen if we ever what to have a release. Rules state clear that once frozen, no commits are allowed excepting fixes. What you miss here - or I haven't made it clear enough - is that the auth* commit doesn't backport any new features, improvements, etc, but backports a *cleanup* of these modules, cleanup which fixes a lot of inconsistencies - which in my opinion goes into fixing area.
If this cause you any inconveniences, I'm really sorry, but our major concern now must be to get a new SER release as best as possible.
bogdan
Juha Heinanen wrote:
Martin Koenig writes:
I, from a user's point of view, am against the reversal of this backport. I like the functionality in 0_9_0 alot and think it is very useful. However, Juha's point regarding performance remains valid.
there are lots of things i like in unstable branch and which i would like to get officially committed to rel_0_9_0, but haven't proposed or done any, because i thought that as advertized, rel_0_9_0 is a frozen branch, where only bug fixes were allowed to be committed.
if the rules have changed, perhaps i'm allowed to commit lcr module, for example, to rel_0_9_0? either we re-open the branch or we don't.
the auth rpid changes that were committed yesterday, will force me to change in MANY rel_0_9_0 proxies the way radius returns caller rpid, i.e., the chance is not backwards compatible.
is there anyone in charge here?
-- juha
Bogdan-Andrei Iancu writes:
What you miss here - or I haven't made it clear enough - is that the auth* commit doesn't backport any new features, improvements, etc, but backports a *cleanup* of these modules, cleanup which fixes a lot of inconsistencies - which in my opinion goes into fixing area.
as i said, auth commit was not backwards compatible with what we had before the commit. more specifically, before the commit, rpid was returned from radius in SIP-RPID reply attribute to authentication query, whereas it now is returned in SIP-AVP attribute. thus all proxies that use radius for authentication stopped working after the commit.
in order to maintain backwards compatibility at radius level, perhaps you could add a check for existence of SIP-RPID attribute in the reply and if it exists, assign its value to rpid avp?
-- juha
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
What you miss here - or I haven't made it clear enough - is that the auth* commit doesn't backport any new features, improvements, etc, but backports a *cleanup* of these modules, cleanup which fixes a lot of inconsistencies - which in my opinion goes into fixing area.
as i said, auth commit was not backwards compatible with what we had before the commit. more specifically, before the commit, rpid was returned from radius in SIP-RPID reply attribute to authentication query, whereas it now is returned in SIP-AVP attribute. thus all proxies that use radius for authentication stopped working after the commit.
in order to maintain backwards compatibility at radius level, perhaps you could add a check for existence of SIP-RPID attribute in the reply and if it exists, assign its value to rpid avp?
I have to agree with you are this point. I failed to notice this since it is rather a incompatibility at Radius server level - it's about how exactly the RPID value is sent: old version, as standalone A_SIP_RPID Radius attr, now as A_SIP_AVP Radius attr in "rpid:value" format. As far as I found out, this is the only issue, right? And can be easyly fixed - before loading all general Radius attributes from A_SIP_AVP, also look for A_SIP_RPID for backward compat. (maybe configurable)..
Do you find this acceptable from all point of view - compatibility and cvs ruling?
bogdan
Bogdan-Andrei Iancu writes:
As far as I found out, this is the only issue, right?
yes, that is the only backwards incompatibility issue.
And can be easyly fixed - before loading all general Radius attributes from A_SIP_AVP, also look for A_SIP_RPID for backward compat. (maybe configurable)..
that is what i suggested. if configurable, then the default should be to look for A_SIP_RPID, so that also ser.cfg remains backwards compatible.
Do you find this acceptable from all point of view - compatibility and cvs ruling?
yes, i would.
-- juha
Juha,
I fixed on cvs the backward compatibility for Radius. There is one module param "rpid_avp" (default value "rpid") - the module will try first to fetch the RPID from the Sip-RPId radius attribute (as it was before) and store it in the rpid_avp AVP. If the rpid_avp is set to empty, the backward compatibility will be disabled.
bogdan
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
As far as I found out, this is the only issue, right?
yes, that is the only backwards incompatibility issue.
And can be easyly fixed - before loading all general Radius attributes from A_SIP_AVP, also look for A_SIP_RPID for backward compat. (maybe configurable)..
that is what i suggested. if configurable, then the default should be to look for A_SIP_RPID, so that also ser.cfg remains backwards compatible.
Do you find this acceptable from all point of view - compatibility and cvs ruling?
yes, i would.
-- juha
My 2 cents worth: Also we experienced the problem of SIP-Rpid suddenly not working. (It took some time and some code reading to figure out that the problem was to be found in the auth_db module, even though auth_radius also was updated.) It was Martin Koenig's serdev posting regarding CVS HEAD that pointed me in the right direction.
IMHO, the committed changes done by Bogdan did not only fix Rpid issues, but also introduced new functionality in the auth_radius module (i.e. ability to load SIP-AVPs as part of a radius auth). Before the discussion started on these mailing lists, I was surprised that such functionality was introduced so close to release. I did not really expect such an extensive code upgrade, and admittedly I would prefer not to get surprises like this... ;-) The loading of SIP-Rpid as part of auth and having to use a separate function in avp_radius for loading SIP-AVPs for caller has seemed a bit odd and makes it a bit difficult on the RADIUS side (we use a commerical RADIUS server). So, I agree with Bogdan that introducing SIP-AVP loading in authentication is a clean up that makes sense. However, I believed that the avp_radius module was a way to introduce avp loading in 0.9.0 without changing the code of the auth modules?! Why not address this earlier?
My personal opinion: Despite the latest commits, AVP loading from RADIUS is still in transition from being an add-on (avp_radius module) to being integrated in auth_radius and uri_radius. I would love to get rid of one auth (we have three today for each INVITE).
As long as the backwards SIP-Rpid compatibility is there, I'm fine with the commits done.
So, some comments to how I view the RADIUS-based avpair loading in ser-0.9.0: It looks like the loading of SIP-AVPs in auth_radius load all attributes without the "caller_" prefix, while our scripts use caller_* and callee_* prefixed AVPs. This results in the need for renaming all ser.cfg avp references when moving from avp_load_radius("caller") to loading through radius_proxy_authorize().
Also, it seems that both radius_www_authorize and radius_proxy_authorize will load the same set of SIP-AVPs. Both use SIP-Session as Service-Type and it is thus not possible to avoid returning SIP-AVPs for a REGISTER, but do so for INVITEs. Though not directly a critical problem, our RADIUS servers do complex configuration evaluations and use Session-Type to filter out which evaluations and thus avpairs to return. A REGISTER is a plain authentication + authorization on the SIP service, while an INVITE is a more complex evaluation (that is: if SIP-AVPs are to be returned.) Another question is if it is always so that SIP-AVPs should be returned when Session-Type=SIP-Session. The avp_radius module uses SIP-Caller-AVPs and SIP-Callee-AVPs, thus giving a great deal of flexibility.
Ok, finally, loading SIP-AVPs as part of the auth makes sense, but from a user point of view it would be natural to phase out the avp_radius module when doing so. Now avp_load_radius("callee") is still left (radius_does_uri_exist seems to be the natural replacement). This gives another question: Should Session-Type=Call-check always indicate that SIP-AVPs for callee should be returned, or is there other scenarios? (I don't really know, we haven't, but others may?)
g-)
Bogdan-Andrei Iancu wrote:
Juha Heinanen wrote:
Bogdan-Andrei Iancu writes:
What you miss here - or I haven't made it clear enough - is that the auth* commit doesn't backport any new features, improvements, etc, but backports a *cleanup* of these modules, cleanup which fixes a lot of inconsistencies - which in my opinion goes into fixing area.
as i said, auth commit was not backwards compatible with what we had before the commit. more specifically, before the commit, rpid was returned from radius in SIP-RPID reply attribute to authentication query, whereas it now is returned in SIP-AVP attribute. thus all proxies that use radius for authentication stopped working after the commit.
in order to maintain backwards compatibility at radius level, perhaps you could add a check for existence of SIP-RPID attribute in the reply and if it exists, assign its value to rpid avp?
I have to agree with you are this point. I failed to notice this since it is rather a incompatibility at Radius server level - it's about how exactly the RPID value is sent: old version, as standalone A_SIP_RPID Radius attr, now as A_SIP_AVP Radius attr in "rpid:value" format. As far as I found out, this is the only issue, right? And can be easyly fixed - before loading all general Radius attributes from A_SIP_AVP, also look for A_SIP_RPID for backward compat. (maybe configurable).. Do you find this acceptable from all point of view - compatibility and cvs ruling?
bogdan
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Greger V. Teigre writes:
My personal opinion: Despite the latest commits, AVP loading from RADIUS is still in transition from being an add-on (avp_radius module) to being integrated in auth_radius and uri_radius. I would love to get rid of one auth (we have three today for each INVITE).
i too have floated the idea that authentication would return from radius caller avps and does_uri_exist function callee avps. this way you would not need to make any extra radius calls. because both caller and callee may have the same attributes, i suggested to add "caller_" and "callee_" prefix into avp names. using rpid as an example, callee can very well have an rpid that will be used if callee decides to forward the call.
This gives another question: Should Session-Type=Call-check always indicate that SIP-AVPs for callee should be returned, or is there other scenarios? (I don't really know, we haven't, but others may?)
my thinking has been that service type implicitly tells, which attributes should be returned. if Service-Type is SIP-Session, radius returns caller attributes and in case of Call-Check callee attributes. you could still use the same database table for both.
regarding removing auth_radius, i need it for other things (such as sems related stuff) and would thus like to keep it.
-- juha
See inline.
Juha Heinanen wrote:
My personal opinion: Despite the latest commits, AVP loading from RADIUS is still in transition from being an add-on (avp_radius module) to being integrated in auth_radius and uri_radius. I would love to get rid of one auth (we have three today for each INVITE).
i too have floated the idea that authentication would return from radius caller avps and does_uri_exist function callee avps. this way you would not need to make any extra radius calls.
With Bogdan's changes I thought this was the plan, not just an idea?! It seemed sort of halfway to add sip-avp loading to authentication and not does_uri_exist
because both caller and callee may have the same attributes, i suggested to add "caller_" and "callee_" prefix into avp names.
Again, I though (maybe just hoped) that this adopted as the convention. I believe there are many people who assume, as I do, that functionality introduced in 0.9.0 will be followed through in subsequent versions.
using rpid as an example, callee can very well have an rpid that will be used if callee decides to forward the call.
I have exactly this issue with a Cisco GW. I need to use callee rpid for making sure that billing works correctly with an Ericsson AXE.
This gives another question: Should Session-Type=Call-check always indicate that SIP-AVPs for callee should be returned, or is there other scenarios? (I don't really know, we haven't, but others may?)
my thinking has been that service type implicitly tells, which attributes should be returned. if Service-Type is SIP-Session, radius returns caller attributes and in case of Call-Check callee attributes. you could still use the same database table for both.
Yes, I think this is fine as long as a SIP-Session always has caller in username and Call-Check always callee. One immediate problem is what I pointed out in my last post: There seems to be impossible to differentiate between a REGISTER auth and an INVITE auth. Though not off the top of my head, there are probably scenarios where it would be useful to be able to return AVPs used in registration only.
regarding removing auth_radius, i need it for other things (such as sems related stuff) and would thus like to keep it.
avp_radius, you mean? I didn't know, but then I don't use sems. g-)
Hello,
Juha Heinanen wrote:
Greger V. Teigre writes:
My personal opinion: Despite the latest commits, AVP loading from RADIUS is still in transition from being an add-on (avp_radius module) to being integrated in auth_radius and uri_radius. I would love to get rid of one auth (we have three today for each INVITE).
i too have floated the idea that authentication would return from radius caller avps and does_uri_exist function callee avps. this way you would not need to make any extra radius calls. because both caller and callee may have the same attributes, i suggested to add "caller_" and "callee_" prefix into avp names. using rpid as an example, callee can very well have an rpid that will be used if callee decides to forward the call.
In my oppinion, it is an administrator's issue to be able to distinguish between caller and callee attributes. However, the does_uri_exist functionality is still missing. A common practice with prefixes is certainly recommended.
In my experience, anything possible needs to be done to avoid as many radius queries as possible, because they are very expensive performance-wise.
This gives another question: Should Session-Type=Call-check always indicate that SIP-AVPs for callee should be returned, or is there other scenarios? (I don't really know, we haven't, but others may?)
my thinking has been that service type implicitly tells, which attributes should be returned. if Service-Type is SIP-Session, radius returns caller attributes and in case of Call-Check callee attributes. you could still use the same database table for both.
I don't see the main impact on being able to diff between a REGISTER and INVITE auth request. This is mainly an issue when it comes to very complex radius database back-ends. From my experience, not too much ressources are wasted here because the db backends on production radius services are usually powerful enough to serve even the REGISTER load of a highly populated Ser Proxy.
regarding removing auth_radius, i need it for other things (such as sems related stuff) and would thus like to keep it.
Referring to avp_radius, I wouldn't remove it. It's interesting for non-auth proxies like outbound proxies.
Going back to the original discussion, please do not revoke the given functionality in rel_0_9_0, but create a legacy option (with default=on) to fall-back to the outdated Sip-Rpid reply attribute when it comes to RPID.
Regards, Martin Koenig
Hello,
I think Juha has a point. Those changes are not backwards compatible, it's more than just a bug fix. Even I am not sure that everything works as expected because I did not test it properly. I was hoping that backporting them would not introduce any troubles, but this does not seem to be true.
Bogdan, please revert the changes and we will stick to the original version. I think we should not be doing backwards incopatible changes within that release.
It would be also unfair to others (Jamey) who were denied to do changes in 0.9.0 branch because it was frozen.
Jan.
On 22-04 13:15, Bogdan-Andrei Iancu wrote:
Juha,
indeed rel_0_9_0 is and will stay frozen if we ever what to have a release. Rules state clear that once frozen, no commits are allowed excepting fixes. What you miss here - or I haven't made it clear enough - is that the auth* commit doesn't backport any new features, improvements, etc, but backports a *cleanup* of these modules, cleanup which fixes a lot of inconsistencies - which in my opinion goes into fixing area.
If this cause you any inconveniences, I'm really sorry, but our major concern now must be to get a new SER release as best as possible.
bogdan
Juha Heinanen wrote:
Martin Koenig writes:
I, from a user's point of view, am against the reversal of this backport. I like the functionality in 0_9_0 alot and think it is very useful. However, Juha's point regarding performance remains valid.
there are lots of things i like in unstable branch and which i would like to get officially committed to rel_0_9_0, but haven't proposed or done any, because i thought that as advertized, rel_0_9_0 is a frozen branch, where only bug fixes were allowed to be committed.
if the rules have changed, perhaps i'm allowed to commit lcr module, for example, to rel_0_9_0? either we re-open the branch or we don't.
the auth rpid changes that were committed yesterday, will force me to change in MANY rel_0_9_0 proxies the way radius returns caller rpid, i.e., the chance is not backwards compatible.
is there anyone in charge here?
-- juha
Serdev mailing list serdev@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serdev
Jan,
please see the inline comments.
bogdan
Jan Janak wrote:
Hello,
I think Juha has a point. Those changes are not backwards compatible, it's more than just a bug fix. Even I am not sure that everything works as expected because I did not test it properly. I was hoping that backporting them would not introduce any troubles, but this does not seem to be true.
I had a private chat with Juha and the backward compatibility is solved via a small correction - Juha already tested, so I guess from this point of view shouldn't be any issues.
Bogdan, please revert the changes and we will stick to the original version. I think we should not be doing backwards incopatible changes within that release.
As we privately both agreed one month ago, the old code for auth* wasn't up to a release level. Personally, I wouldn't make the revert since it will mean I accept wicker code into the official release . But of course you are the maintainer of these modules and you have the liberty to revert the changes if you consider it the best solution.
I will commit the backward compatibility fix, since Juha really needs it to cop with his Radius configuration. After that it's your decision to revert all or not.
-
Bogdan-Andrei Iancu -
Francesco Bottà -
Greger V. Teigre -
Jan Janak -
Juha Heinanen -
Martin Koenig