"David Woolley" <david@ex.djwhome.demon.invalid> wrote in message
news:j13l9f$dvp$1@dont-email.me...
> News Reader wrote:
>
>> What I need or want is the correct format for passing one's service
>> provider or registration username and password. E.g. when accessing an
>> ftp server via URI one use the format (as I loosely recall):
>> username:password@server.server/targetpath .
>
> http://www.ietf.org/rfc/rfc3261.txt page 148.
>
> Note that the inclusion of passwords is not advised and the service
> provider may well not accept them.
Hi,
Thank you very much for your reply David.
I note your observations regarding sensibility, security and service
provider acceptance(/ability).
I had reviewed the IETF draft (document). However, as an RFC it was
intelligible, where, as much other reference material or documentation in
this domain, it seemed to focus or reference own or local system context.
I.e. one passing a user and or password for their own system, extension or
account, in order to then perform a configuration, identification or
setting, for an (one's) own account or extension, number, etc.
The context I am looking for is of calling a foreign party (destination
number) using my (or "local" [{my} service provider]) authentication. I.e.
context - run of the mill or generic SIP voice service provider (VSP?):
Process: SIP User <--> VSP Server <--> Destination Phone
URI?(?): Destination (Target) Phone <--> Authentication Details @ VSP
Server (domain)
SIP User rather than registering to or with VSP SIP server, sends combined
dial string (destination or target phone number) and user (customer account)
authentication credentials (like for pass through dialling [and
authentication / authorisation]).
Hence, what "string" or URI should be used (presented)? All common(ly
available) or technical examples show user:pass as initial string, where all
normal SIP URI's I have seen or know (that I can remember ! - aaagghhhh..
used to know or had / have seen the particular SIP URI with authentication
format I am on about[!] [just wish I could remember or recall where I had
seen the reference; where the reference is stored])... start with
destination number (target) @ domain .
All the examples in technical reference materials seem to propose
authentication details @ domain ; extra or extended switches, settings,
parameters or object[ive] (authentication/ed functions or options)
(typically seemingly not including an onward dial or target destination
field or number entry, field, etc.!?).
Thanks!
lol... so simple... so lost or wheat for chaff. hmmm..
Best wishes,
News Reader