Subject: [Speermint] draft-uzelac-speermint-use-cases-oo.txt

From: "Uzelac, Adam" <[email-masked]>
Date: Mon, 16 Oct 2006 17:50:14 -0400

If you want to take a peak at some current practices (not the
intentional omission of 'best') - see
http://www.voiploser.com/misc/draft-uzelac-speermint-use-cases-oo.txt -
I punted to I-D Action today, but after the 9am ET deadline for
consideration in San Diego.  :(  I would still appreciate comments
though.  It's not pretty, but it's something to noodle on.

-AU 

PS - this is an attempt to capture what's going on out there today - NOT
an endorsement.

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

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 17 Oct 2006 17:53:23 +0200

> though.  It's not pretty, but it's something to noodle on.

Thanks Adam, this is a helpful document.

Two questions:

Within your descriptions, you often use the phrase

 The <proxy/sbc> performs some next-hop determination for the called
 party.  This can be done via ENUM/DNS/Redirect 3XX multiple choices
 and/or static routing.

I'm wondering if these decisions are number or URI based. In the
case of ENUM, that obviously number-based. For the SIP redirect:
does the redirect server expect a number in the user-part of
the SIP AoR and looks that up in its routing table, or is this
a decision based on the domain part of the URI?

Consider e.g. the worst case

   +----VSP(o)-------+-----VSP(T)-------+---VSP(t)------+ 
   +--Orig Domain----+--Transit Domain--+--Term Domain--+ 
                     |                  | 
    +-----+    +-----+-----+      +-----+-----+   +-----+ 
    |Proxy|----| SBC | SBC |------| SBC | SBC |---|Proxy| 
    +-----+    +-----+-----+      +-----+-----+   +-----+ 
        |            |                  |             | 
        |            |                  |             | 
        |            |     +-------+    |             | 
        |                  | Proxy |                  | 
       +--+                +-------+                 +--+ 
       |UA|                                          |UA| 
       +--+                                          +--+ 

where a lot of boxes need to make routing decisions:

Is there a single number->URI translation at the start of
the call plus domain based routing decisions on the way,
or is the whole process a sequence of number->URI
mappings where the URIs vary in each step and just 
specify the next hop contact information? 

Thanks,

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 17 Oct 2006 14:01:25 -0400

Otmar - Thanks for the comment.  I am glad the draft helped.  Answers to
your questions...The input to the route determination are nearly always
numbers.  Numbers in the user-part specifically.  The diagram you
plucked out of the draft is bad, but it's not the worst.  It's just the
most common of the worst.  SBCs are mostly on the Carrier's edges, not
on the Enterprises. Once the B2BUA is prevalent on the Enterprise edge,
the "worst case" would look MUCH worse.  If nothing else, to me this
shows that there should be some urgency around what SPEERMINT is
attempting to address.  We need to start derailing the momentum around
this idiocy of back to back B2BUAs due to the transparency lost. 

On that front - I recall a "Top 10 List" from Dean Willis on SIP
Transparency across a B2BUA - I looked it up and here it is...It's
something to think about I believe.

1) Dialog transparency: The call-ID is the same on "both sides" of the
B2BUA. Proxies have this characteristic. A B2BUA that actually
terminates a dialog on one side and generates a new dialog on the other
doesn't. Some 3GPP AS functions fall into this category, as do 3PCC
controllers.

2) Identity transparency: The user appears to have the same identity on
both sides of the B2BUA. A proxy has this property. An identity
anonymizer doesn't.

3) CSEQ transparency: The B2BUA does not alter CSEQ numbers. A
traditional proxy has this property. A 3GPP P-CSCF does not, as it can
generate a BYE message and then have to manage disjoint CSEQ spaces on
each side.

4) Header transparency: The B2BUA doesn't change headers that transit
it. Proxies have mostly this property, changing only a few headers that
are specifically changed by the proxy function. Proxies don't change
headers they don't understand. 3GPP "proxies" are likely to go to town
changing all SORTS of headers. All with the best of intentions, mind
you.

5) Body transparency: The MIME bodies on the SIP message are not altered
by the B2BUA. Real SIP proxies have this property. Firewall proxies that
modify SDP, and most everything in 3GPP, doesn't.

6) Media transparency: AS with body transparency, but considering only
the media aspects. The 3GPP P-CSCF breaks this transparency rule by
editing one's SDP to meet operator preferences.

7) Topology transparency. Via, Route, Record-Route, Path,
P-Service-Route, and other headers that reveal topology are roughly the
same on both sides of the B2BUA, save for any which uniquely identify
that B2BUA. Proxies have this characteristic. Topology hiding devices
like the dynamicosft "firewall proxy in edge proxy mode" or the 3GPP
THIG don't.

8) Security transparency: The B2BUA doesn't alter security aspects, such
as encryptions, authorization headers, etc. Proxies generally have this
property, but 3GPP stuff  doesn't.

9) Accounting transparency: Stuff used to generate records or track
usage is not altered by a B2BUA with this property. Proxies have this
property. 3GPP is trying to define a P-header (P-original-dialog-ID, I
believe) to provide for accounting transparency across 3GPP AS elements
operating at a low level of transparency.

10) Functional transparency: The task that the user of the UA wants to
accomplish actually works across the B2BUA, rather than being
blocked/distorted by it. proxies generally have this property, with the
caveat the proxy can reject a request if needed. Some 3GPP entities can
mutate functionality beyond all recognition. This is probably the single
most important transparency concept. The rules of a "proxy" as defined
in RFC3162 are there to preserve functional transparency, and anything
that "breaks" those rules is likely to compromise functionality in some
way.

-AU

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, October 17, 2006 11:53 AM
To: Uzelac, Adam
Cc: [email-masked]
Subject: Re: [Speermint] draft-uzelac-speermint-use-cases-oo.txt

On 2006/10/16 23:10, "Uzelac, Adam" <[email-masked]>
wrote:
> http://www.voiploser.com/misc/draft-uzelac-speermint-use-cases-oo.txt 
> - I punted to I-D Action today, but after the 9am ET deadline for 

Two questions:

I'm wondering if these decisions are number or URI based. In the case of
ENUM, that obviously number-based. For the SIP redirect:
does the redirect server expect a number in the user-part of the SIP AoR
and looks that up in its routing table, or is this a decision based on
the domain part of the URI?

Is there a single number->URI translation at the start of the call plus
domain based routing decisions on the way, or is the whole process a
sequence of number->URI mappings where the URIs vary in each step and
just specify the next hop contact information? 

Thanks,

/ol