Subject: [Sipping] Roaming Architecture for SIP

From: "Harry Behrens" <[email-masked]>
Date: Mon, 23 Feb 2004 12:35:42 +0100

We have submitted a draft to the IETF
(draft-behrens-sipping-roaming-architecture-00.txt),
in which we describe a mechanism to enable VoIP roaming based on a
unique ID - the NAI - which constitutes
a handle into the billing relationship for a user.
The original draft has some mistakes in the discussion of the call flows
as well as not being 100% correctly formatted.
We will therefore submit an updated version after the cutoff date, which
we attach in this mail.
Comments etc. are very welcome.

Best regards,

	Harry Behrens
	Karsten Knuettel

Abstract 
 
This draft describes an authentication mechanism which can be used to 
enable users of VoIP to globally roam between any number of ITSPs 
(Internet Telephony Service Providers) without needing to have a prior 
customer or billing relationship with all of them. This enables 
profiles and one-line-billing. 
Providers using this authentication mechanism do neither need full-mesh 
trust relationships or roaming agreements with every other possible 
provider nor do they need to rely on a centralized brokerage entity to 
process calls. 
The Home Network (HN), which handles all AAA for a user attempting to 
use an ITSP's service is determined through a unique identifier 
submitted by the user. This Network Access Identifier [RFC2486] 
contains information about the trust domain or trust realm the user 
belongs to. Based on a simple discovery mechanism a provider can 
establish a trust path to this home network. Once this is established, 
the provider can authenticate the user and check his credit with the 
home network. Accounting and rate information will be sent to the home 
network for mediation and processing.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Feb 2004 13:47:06 -0500

> Comments etc. are very welcome.

I have specific comment inline below, and then a question.

	Paul

>   -  A user registers with the VN (atlanta.com in the call flow 
>       given). The user submits his NAI in new header field 'P-NAI'. 
>       The user submits a bogus URI in both the From and the To header. 
>       (F1 in section 8.2.1)
>   -  The VN recognizes the registration as a P-NAI registration and 
>       sends back a "401 Unauthorized" response, with both the 'From' 
>       and the 'To' URI set to the temporary URI that will be assigned 
>       to the user upon successful authentication and authorization (F2). 

This isn't legal. The From and To (with exception of To-tag) of response 
must be same as in the request.

The question is: why would the UAC want to register with the VN? 
Assuming it is able to send sip messages, (which apparently it can), why 
wouldn't it simply send a REGISTER to its HN?

I presume there must be some service that you intend the VN won't 
perform, that will prevent the UAC from doing this. But it isn't 
apparent what service that is.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Harry Behrens" <[email-masked]>
Date: Tue, 24 Feb 2004 11:53:55 +0100

Dear Paul,

inline

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Montag, 23. Februar 2004 19:47
> An: Harry Behrens
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [Sipping] Roaming Architecture for SIP
> 
> 

This is true. The reason we have this crutch in there is to allow the VN
server to pass a user ID to the client, which the client can use to
register to the VN. This would otherwise have to happen out-of-band,
which we were trying to avoid.
We are thinking about alternative approaches to this requirement and are
grateful for any input.

> apparent what service that is.

The scenario is of a user based e.g. in Berlin/Germany on a business
trip in Beijing/China.
The user will want to both be reachable under his home AOR (for that he
registers with his HN) as well as make use of the VN for local calls,
especially local PSTN breakout (this is why he wants to have a valid
registration with the VN).
Furthermore, in a number of cases, one encounters RTP-proxying, where
around-the-world loops are to be avoided.
Another issue which we foresee is that in the near future hotels,
airports or other semi-closed (walled garden) Internet access points,
will force users through their own VoIP (SIP) proxy infrastructure,
similar to what a lot of sites aleady do in the case of HTTP.

	Harry

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Feb 2004 12:32:44 -0500

Harry Behrens wrote:
>>>      The user submits a bogus URI in both the From and the 
>>
>>To header. 
>>
>>>      (F1 in section 8.2.1)
>>>      sends back a "401 Unauthorized" response, with both 
>>
>>the 'From' 
>>
>>>      and the 'To' URI set to the temporary URI that will 
>>
>>be assigned 
>>

No good idea comes immediately to mind. I'm still not convinced of why I 
would want this at all.

> registers with his HN)

I'm ok with that.

 > as well as make use of the VN for local calls,

Why? His billing relationship is with his HN. Why not let the HN figure 
out the best way to route this calls? If it is via the VN's gateways, 
then it can route the calls to the VN.

> around-the-world loops are to be avoided.

Certainly that is likely to be a bad thing. But does it require a 
signaling identity with the VN to achieve that?

> similar to what a lot of sites aleady do in the case of HTTP.

Sure. But as long as those things are *proxies*, the UA should still be 
able to register with his HN.

Dealing with that depends a bit on how users will be forced. The way 
hotels do it today depends on details of http that won't necessarily 
work for sip.

	Paul

---

From: "Harry Behrens" <[email-masked]>
Date: Wed, 25 Feb 2004 10:54:13 +0100

Paul,

inline.

> > trip in Beijing/China. The user will want to both be 
> reachable under 
> > his home AOR (for that he registers with his HN)
> 
> I'm ok with that.
>

That's nice.
 
> then it can route the calls to the VN.

In all practical experience: if you and your VN is in China and your HN
is in Germany (or any similar setup), who would you want to route your
calls within China?
The HN has an important role to fulfil as the anchor of trust for the
billing relationship, however we don't think it neither feasible nor
realistic nor even desirable from an IETF point of view at this point in
time to have the HN fulfil routing decisions at the HN.
The OSP as defined by ETSI goes into this direction. However this seems
a far too carrier-centric model to be of use in the somewhat more
flexible world of the Internet and specifically ITSPs.
Furthermore, even if my HN has my billing relationship, why should we be
able to assume that this HN knows anything about the topography of VoIP
connections in China?

> signaling identity with the VN to achieve that?

If you put the question like that, no. However, in practice the
RTP-Proxy is normally in the domain/realm of the carrier handling the
PSTN break-out.
How would you suggest for the signalling to happen at the HN and the
media conversion at the VN if break-out is happening at the VN?
Pls. note that we do not assume a VoIP peering agreement between the two
networks (VN, HN). In fact the HN being a VoIP carrier is actually
optional. The emphasis is on the HN to be an "authorized billing
entity".

> hotels do it today depends on details of http that won't necessarily 

Either way, the "walled garden proxy" would probably/possibly want the
user to be registered - even if further registrations such as with the
HN are allowed. 
Again: there is nothing to be gained by putting routing and signalling
decisions for the local domain (i.e. China, VN in the example) to the
HN.
Conversely a lot is to be gained in terms of flexibility in following
the model.

	Harry

> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>