Jiri Kuthan jiri@iptel.org writes:

I'm not sure I understand. You want to account calls to PSTN, is that what you wish to achieve?

Yes. There are I think 4 entities who all want to share one PSTN gateway. Each will receive a different phone bill, and may want to present different source phone numbers to bill specific groups within their DID.

That said, I'm new to telephone stuff, so I may be asking the wrong questions or using the wrong words.

• why can't you account to the accounting system from the gateway -- I think of gateways as a very good place for accounting -- they know everything about a call, including the PSTN side and media status; they are thus in better shape to account than a proxy is

For call length, sure, but I need to tell the PSTN gateway the source of the call, and we don't want it to be the one mapping sip:graff@isc.org into a 10-digit phone number.

• what do you mean by rewriting identities? are you thinking of a proxy which authenticates incoming requests from upstream and authenticates to downstream gateway as someone else? why?

See above.

• what accounting mechanims would you like to use? radius?

that, or sql, or syslog.

Or am I guessing completely wrong and you mean you wish to have the ability to replace a native sip user name "john.doe" with "his" phone number 1234, so that the gateway sees "1234" as username and can propagate it to PSTN?

Exactly. Only it will see 65077970xx, but that's beside the point.

--Michael

I see these every now and then...

Jan 10 20:22:35 build ser[14278]: authorize(): Invalid nonce value received, very suspicious ! Jan 10 20:22:53 build ser[14278]: is_user(): No authorized credentials found (error in scripts) Jan 10 20:23:28 build ser[14278]: is_user(): No authorized credentials found (error in scripts) Jan 10 20:40:45 build ser[14272]: db_close(): Invalid parameter value Jan 10 20:40:56 build ser[14419]: authorize(): Invalid nonce value received, very suspicious ! Jan 10 20:41:09 build ser[14421]: WARNING: sip_msg_cloner: header body ignored: 4096

I think it is when I stop and start the server manually. Should I be worried? Is there a more graceful way of restarting?

---greg

At 04:59 AM 1/13/2003, Jan Janak wrote:

...

Jan 10 20:22:53 build ser[14278]: is_user(): No authorized credentials found (error in scripts)

This means you call some function from auth module and didn't call authorize before that. Some functions from auth module need authorized credentials and if issue this error if the message contains no authorized credentials.

Just one short note on why it is this way: any processing based on digest id (like is_user does) is only meaningful after the authenticity of digest id was verified. Othewise any request sender could put any digest id in request (e.g., "foobar" or "gwbush") and you would use it. Thus, call an authorization action first.

-Jiri

Nils Ohlmeier nils@ohlmeier.de writes:

A proxy can challenge Invites and Byes, but should not do this with external Invites to your local user. Otherwise your your user wouldn't be reachable from outside.

I implemented something much like this:

if (to me): if register

www_authorize or fail if not a valid register

done

if claiming to be "From" one of the domains I accept registrations for

proxy_authorize

done

if not to me (I'm relaying for a local phone to an external address)

proxy_authorize (once again, based on from address)

done

--Michael

makes perfect sense.

-Jiri

At 05:49 PM 1/12/2003, Michael Graff wrote:

Nils Ohlmeier nils@ohlmeier.de writes:

...

A proxy can challenge Invites and Byes, but should not do this with external Invites to your local user. Otherwise your your user wouldn't be reachable from outside.

I implemented something much like this:

if (to me): if register

           www_authorize or fail if not a valid register

           done

   if claiming to be "From" one of the domains I accept
   registrations for

           proxy_authorize

           done

if not to me (I'm relaying for a local phone to an external address)

   proxy_authorize (once again, based on from address)

   done

--Michael _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/

At 01:03 AM 1/11/2003, Michael Graff wrote: [...]

That said, I'm new to telephone stuff, so I may be asking the wrong questions or using the wrong words.

Don't worry, that's mostly me where confusion comes from.

I understand now -- you wish that requests From: sip:graff@isc.org will appear to the destination as From: sip:65077970xx@isc.org so that a gateway can propagate the number down to PSTN and use it for accounting.

I think the right way to do this thing is to have a proxy server attaching a "network asserted identity" (NAI) to the request. The NAI piece of data includes then the desired number. This has been recently discussed on the IETF/SIPPING mailing list, thread "URIs for Gateways". The major drawback of this method is it is still under discussion, it will take quite long to complete (if ever, you never know in IETF).

Changing content of From header field by proxy is imho too risky and could result in interoperability problems. Pre-3261 implementations use from to identify transactions and dialogs. 3261 implementations only use from-tag, but it is hard to tell which currently available implementations really do that. Some people might be concerned too about a possible damage to transparency, which -- similarly to how NAT's rewrite packets and cause confusion -- might result in confusion.

So I may be too pesimistic or ignorant, but I unfortunately only see these imperfect options: - account from a proxy server and use some local translation (graff->65077970xx) during the accounting process; ignore the issue of displaying 65077970xx down in PSTN - use 65077970xx as SIP user id and 'graff' as an alias for incoming request - wait until NAI is standardized in IETF and deployed in SIP products - rewriting From at a quite high risk of interoperability problems

What do you think?

-Jiri

<sorry>for delay, I'm travelling</sorry>

At 09:59 PM 1/14/2003, Michael Graff wrote:

Jiri Kuthan jiri@iptel.org writes:

...

• rewriting From at a quite high risk of interoperability problems

If this is only used between this specific PSTN gateway (a Cisco box) and SER (we require it to be in the loop for this PSTN path) this may be the fastest way. It is a 1:1 translation anyway, so we could really say "from source SER s/graff@isc.org/65077970xx@isc.org/ and reverse the translation on the other way (or just let it talk directly to us, since that's not the problem direction.)

Yes, I know it's a hack, and not a long-term fix. I think the NAI thing seems like the fix we'd want.

When is SIP 3.x coming out that fixes all the NAT, proxy, and other protocol issues? Sorry, I'm being cynical. :)

Well, I am neither happy about IETF's pace and ignorance of issues related to SIP operation -- vendors and marketeers are there simply ahead of operators.

I'm trying to think out how your hack would be implementable. We would have to enforce record-routing so that subsequent transactions can be rewritten too. A SAT module (SIP Address Translation :)) would rewrite URI in From of both initial requests, and their replies.

It would take transaction processing as long as some transactions may be rewritten, some not and one needs to 'remember' replies of which transactions shall be rewritten.

We then still need to be able to rewrite transactions originated by the called party, i.e, if called gateways send a Bye with "650" in To, it needs to be rewritten back to "mike". The caller would otherwise very likely not recognize the BYE as a part of an ongoing transaction. A hack to achieve that might be use of a new record-routing parameter. The parameter would tell "this belongs to a translated dialog and needs to be translated too". The parameter could include the original address as well as the rewritten one -- that would save an additional database lookup. It could look like ;satin=mike@foo.bar;satout=650@foo.bar. If a request from caller (satin=from) hits the proxy, it now nows how to rewrite From: without database lookup. If a request from callee arrives (satout=to), the server knows too and rewrites To header field reversely.

does it sound reasonable?

-Jiri