[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt
> -- only that more than one clearinghouse may be involved.
Glad for this clarification, but would like to make sure we have the
same understanding:
1. There is a choice between several clearinghouses, just like having
more than one credit card, or
2. Use you own clearinghouse, which in turn settles though another
clearinghouse. This is a valid scenario as well, but inter-clearinghouse
transactions would be quite removed from SIP and may use something else,
such as web services as a mechanism.
This brings back the point, why SIP AAA should not target AAA platforms
that are not known to be used commercially, like DIAMETER discussed in
other messages here (the SIP AAA I-D), but web services, so as to be
consistent with e-commerce going forward.
Henry
> -----Original Message-----
> From: Kevin Summers [mailto:Kevin.Summers@sonusnet.com]
> Sent: Friday, February 14, 2003 2:21 PM
> To: Henry Sinnreich; sip@ietf.org
> Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt
>
>
> My intent was not to suggest that we revert to a PSTN model
> -- only that more than one clearinghouse may be involved. How
> a set of ISPs choose to do business should be their choice.
> Seems that multi-party scenarios may also require support of
> more than one token -- for which context of the token is needed.
>
> -----Original Message-----
> From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com]
> Sent: Friday, February 14, 2003 2:03 PM
> To: 'Kevin Summers'; sip@ietf.org
> Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt
>
>
> > Any comments?
>
> Kevin,
>
> > that multiple domains might "touch" a call and there could be a
> > requirement for multiple OSP tokens within a request. Would it make
> > sense to include something akin to the Authorization
> header's realm
> > string with the token?
>
> The model for the inter-domain AAA is that only the end
> networks and a possible clearing house server are aware of
> each call in the 'retail' mode. There may be several transit
> networks, but for scalability reasons, they are transparent.
> It is a matter of peering agreements between ISPs to handle
> inter-ISP traffic, not matter what the application is.
>
> If transit networks would be aware of each call and
> accounting would be required, we would be back to the PSTN
> model, not a desirable model for the Internet IMHO.
>
> Having said this, domains may chose to insert multiple
> tokens. But this is not a good reason for the IETF to
> legitimize PSTN-like complications, per call billing and
> multi-party settlement models.
>
> My two cents, Henry
>
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On
> > Behalf Of Kevin Summers
> > Sent: Friday, February 14, 2003 11:07 AM
> > To: sip@ietf.org
> > Subject: RE: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt
> >
> >
> > I think that it might be likely (actually, highly likely)
> > that multiple domains might "touch" a call and there could be
> > a requirement for multiple OSP tokens within a request. Would
> > it make sense to include something akin to the Authorization
> > header's realm string with the token? I am thinking that it
> > would be something that qualifies the token.
> >
> > Any comments?
> >
> > -Kevin
> >
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Friday, February 14, 2003 6:46 AM
> > Cc: sip@ietf.org
> > Subject: [Sip] I-D ACTION:draft-johnston-sip-osp-token-04.txt
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> >
> >
> > Title : Session Initiation Protocol Private Extension
> > for an
> > OSP Authorization Token
> > Author(s) : A. Johnston, D. Rawlins
> > Filename : draft-johnston-sip-osp-token-04.txt
> > Pages : 9
> > Date : 2003-2-13
> >
> > This draft proposes a private extension to the Session Initiation
> > Protocol (SIP) for carrying OSP (Open Settlements Protocol)
> > authorization tokens in applications such as clearinghouses.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-johnston-sip-osp-tok
> > en-04.txt
> >
> > To remove yourself from the IETF Announcement list, send a
> message to
> > ietf-announce-request with the word unsubscribe in the body
> > of the message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username "anonymous" and a password of your e-mail
> > address. After logging in, type "cd internet-drafts" and then
> > "get draft-johnston-sip-osp-token-04.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > mailserv@ietf.org.
> > In the body type:
> > "FILE /internet-drafts/draft-johnston-sip-osp-token-04.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
> > MIME-encoded form by using the "mpack" utility. To use this
> > feature, insert the command "ENCODING mime" before the "FILE"
> > command. To decode the response(s), you will need "munpack" or
> > a MIME-compliant mail reader. Different MIME-compliant
> > mail readers
> > exhibit different behavior, especially when dealing with
> > "multipart" MIME messages (i.e. documents which have been split
> > up into multiple messages), so check your local documentation on
> > how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail
> > reader implementation to automatically retrieve the ASCII
> > version of the Internet-Draft.
> > _______________________________________________
> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current
> > sip Use sipping@ietf.org for new developments on the
> > application of sip
> >
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip