Subject: RE: [Speermint] Reachability

From: "Stastny Richard" <[email-masked]>
Date: Tue, 4 Apr 2006 09:55:30 +0200

Hadrian added some more details to my previous question.

I would like to add more two issues:

1. A Public User Identity (i.e. a public AoR) is what
the T-customers perceives what it is, or what he has been 
sold.

If I get an AoR with the remark I may put it on
my business card (say like an E.164 number or a
e-mail address), as 3GPP is explaining it,
I assume the AoR to be "public". You do
not put your internal extension of a PBX on
your business without any further remark.

2.
> Actually, to be very specific ultimate target of the AoR can be "sip
> reachable" but not IP reachable.  But I think for now we should ignore
the
> implications of that, unless it becomes a problem.

A typical example of this would be a (non-transparent) SBC with
a B2BUA. So we should ignore such beasts?

Fine with me ;-)

Richard

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 8:01 AM
> To: 'Reinaldo Penno'; [email-masked]
> Subject: RE: [Speermint] Reachability
> 
> Hi Reinaldo,
> Comments inline...
> 
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:[email-masked]]
> >
> > Maybe I'm missing something, but given that this workgroup is
interested
> > only in call routing (E.164 is out of scope), do we really need to
care
> > about that? An AoR in the end will be translated to an IP address,
and
> > IP addresses have a very good definition of public and private (in
IPv4
> > and IPv6).
> 
> I don't understand fully what you mean.  An AoR is only fully
"translated"
> to an IP Address (and really to a contact URI) by the AoR's domain.
So
> what
> you're saying is if the AoR's user-part represents a consumer behind a
> home
> NAT (a private IP), then it is a private AoR; but for those consumers
who
> don't use home-NATs then it's a public AoR?  And if the AoR gets
> translated
> into an IP by a registrar inside a private IP subnet, and somehow it
later
> gets translated into the public IP address space, that's also private
> because the AoR was translated to a private IP originally?
> 
> Or maybe you mean what the domain part of the AoR resolves to?
> 
> > For you to be "SIP reachable", you need to be IP reachable first,
let's
> > not forget about that. And if you are IP reachable, you could
> > potentially be SIP reachable by registering to some free SIP service
(or
> > the SIP "domain" above you in the hierarchy...if this was the
email/DNS
> > model).
> 
> Actually, to be very specific ultimate target of the AoR can be "sip
> reachable" but not IP reachable.  But I think for now we should ignore
the
> implications of that, unless it becomes a problem.
> 
> -hadriel
> 
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 4 Apr 2006 12:02:37 -0400

Hi Richard,
Comments inline...

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 3:56 AM
> To: Hadriel Kaplan; Reinaldo Penno; [email-masked]

That's not for me to say, I'm not in legal.  But I wonder, if you put a
private extension on your business card and don't add extra words, does it
now mean it has to be publicly reachable, simply because you or your card
printer made a mistake?  ;)  Again, I think operators want to make the AoR's
reachable publicly, by the very fact this working group exists.  Who the AoR
belongs to, or which portion of it, is a legal issue I know nothing about.

> a B2BUA. So we should ignore such beasts?

I'm not sure how you meant it, but that is NOT the typical example at all,
and a common misconception I think; SBCs don't block IP reachability.  The
very fact that the SBC is not "transparent" as a firewall makes it virtually
impossible for the SBC to do, and it's not what the operators of SBCs
typically wish to do.  The only thing that could do such a thing in a
service provider infrastructure typically is a router.  So are they now evil
beasts in the IETF's eyes?  :)

What SBCs do is _enable_ reachability.  If the operator didn't want
reachability they'd simply pull the plugs.  

It could be that the user's UA is behind a NAT, and in that sense they're
not IP reachable and it's true an SBC can make them so through SIP, but in
theory the UA could make themselves so with STUN/ICE. (in some ways such an
SBC is a TURN server from a media perspective, but it just uses the SIP
signaling to do TURN instead of a new protocol)  Providing NAT traversal is
not the main reason SBCs are used, typically.

It could also be that there is a privately-addressed IP VPN of SIP nodes,
and the SBC enables them to communicate out and be reachable from the
outside.  So if you meant it that way, then yes, an SBC enables you to reach
an AoR target in case you don't have IP reachability.  But from the aspects
of the AoR resolving to an IP (whatever that means) which was the context of
the discussion, we should be able to ignore that piece.  :)

-Hadriel