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(a)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(a)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(a)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" &lt;bogdan(a)voice-system.ro&gt; To: "SER developer mailing list" &lt;serdev(a)lists.iptel.org&gt; Cc: "serusers" &lt;serusers(a)lists.iptel.org&gt; Sent: Tuesday, April 19, 2005 1:12 PM Subject: [Serdev] Auth* changes

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" &lt;bogdan(a)voice-system.ro&gt; To: "Francesco Bottà" &lt;francesco.botta(a)eutelia.it&gt; Cc: "SER developer mailing list" &lt;serdev(a)lists.iptel.org&gt;rg>; "serusers" &lt;serusers(a)lists.iptel.org&gt; 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(a)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(a)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(a)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" &lt;bogdan(a)voice-system.ro&gt; >>To: "SER developer mailing list" &lt;serdev(a)lists.iptel.org&gt; >>Cc: "serusers" &lt;serusers(a)lists.iptel.org&gt; >>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 &gt;&gt;&gt;serdev(a)lists.iptel.org >>>http://lists.iptel.org/mailman/listinfo/serdev >>> >>> >>> >> >> >> >>

What's wrong with the LCR module that overrides the rpid_avp value?

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?

with "from uri" have you in mind the rules that apply to lcr algorithm, not change the from HF in the sending INVITE??

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..

Bogdan-Andrei Iancu writes: 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.

i tried it with lcr module and didn't have any problems.

Bogdan-Andrei Iancu writes: sure callee uri can also have rpid associated with it. 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.

Martin Koenig writes: 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: 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?

Bogdan-Andrei Iancu writes: yes, that is the only backwards incompatibility issue. 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. yes, i would. -- juha

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).

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?)

Greger V. Teigre writes: 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.

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.

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.