Subject: [Speermint] [wg-business] WGLC for draft-ietf-speermint-terminology-12

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 4 Sep 2007 10:31:45 -0400

Title		: SPEERMINT Terminology
Author(s)	: D. Malas, D. Meyer
Filename	: draft-ietf-speermint-terminology-12.txt
Pages		: 13
Date		: 2007-8-15
	
This document defines the terminology that is to be used in 
   describing Session PEERing for Multimedia INTerconnect (SPEERMINT).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-speermint-terminology-12.
txt
========================================================================
==================
The intent of the last call is to solicit comments before submitting the
ID to the IESG.

The purpose of a working group Last Call is in the style of "speak now
or forever hold your peace" in case there are fundamental objections
which have not gotten previous or adequate discussion, or minor errors
which need correction.

Working group last call will extend for 2 weeks from today, 4 September
2007, until 18 September 2007 (though we can modify that if new issues
come up).

Please post any comments in reply to the list, as well as to the
editor(s) of this draft.

Regards,

Jason & Dave

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

---

From: "David Schwartz" <[email-masked]>
Date: Tue, 18 Sep 2007 12:34:10 +0200

Sorry for the last minute deal but I just have one small comment.

After reading and rereading and rereading again I think the federation
section is missing a sentence along the following lines...

"A federation facilitates and is the context within which the three
peering models described in sections 4.2.1 - 4.2.3 exist."

Cheers,

David

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2007 5:32 PM
To: [email-masked]
Cc: Malas, Daryl; Peterson,Jon
Subject: [Speermint] [wg-business] WGLC for
draft-ietf-speermint-terminology-12

Regards,

Jason & Dave

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 18 Sep 2007 08:48:05 -0400

Just a reminder that WGLC on this draft closes tomorrow.  If you have
any comments, please post them to this list.

Regards
Jason 

> Sent: Tuesday, September 04, 2007 10:32 AM
> To: [email-masked]
> The intent of the last call is to solicit comments before 
> submitting the ID to the IESG.
> 
> The purpose of a working group Last Call is in the style of 
> "speak now or forever hold your peace" in case there are 
> fundamental objections which have not gotten previous or 
> adequate discussion, or minor errors which need correction.
> 
> Working group last call will extend for 2 weeks from today, 4 
> September 2007, until 18 September 2007 (though we can modify 
> that if new issues come up).
>

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 18 Sep 2007 17:48:35 +0200

> any comments, please post them to this list.

Ok, I'll bite (sorry for the last minute input).

>
>2.  SPEERMINT Context 
>
>   while the horizontal lines indicate working group scope. While the 
>   SPEERMINT working group is not limited (or coupled in any way) to the 
>   use of E.164 numbers, in the case shown here an E.164 number [5] is 
>   used as a key in an E.164 to Uniform Resource Identifier (URI) 
>   mapping (ENUM [4]). That URI is in turn used to retrieve a Naming 
>   Authority Pointer (NAPTR) record [3], which is in turn resolved into 
>   a SIP URI.  Call routing is based on the resulting SIP URI. 

This is an incorrect description of ENUM.

The E.164 number is turned into a FQDN, and based on that FQDN the DNS
is queried for NAPTR records. I recommend changing the last sentences to

"The result of this step (which involves looking up NAPTR records
in the DNS) is a SIP URI, on which the subsequent call routing is based."

>   Note that 
>   the call routing step does not depend on the presence of an E.164 
>   number. Indeed, the resulting SIP URI may no longer even contain any 
>   numbers of any type. In particular, the SIP URI can be advertised in 
>   various other ways, such as on a web page. 
>

Correct.

I have issues with this diagram: The basic idea is good and helpful, but
it isn't clear what piece of data is actually handed off between the
layers.

>           E.164 number <--- Peer Discovery  

I don't understand what "Peer Discovery" is doing here. IMHO that's
definitly a part of the speermint WG's work and thus should not
appear in the ENUM section of the diagram.

>                | 
>                | <--- ENUM lookup of NAPTR in Domain Name System (DNS) 
>                | 
>                | 
>                | ENUM Working Group Scope 
>           =====+==================================================== 
>                | SPEERMINT Working Group Scope 
>           Lookup 
>           Discovery <--- Session Establishment Data (SED)                    
>           SIP URI 

According to the SED definition below, SED is definitly not
the input into the speermint WG scope; instead I see it as
the result of this step:

>                | 
>                | <--- Federation Detection, Policy 
>                |      Lookup, and Service Location 

>                | 
>                | 
>           Hostname <--- Addressing and session establishment 
>                | 

>                | SPEERMINT Working Group Scope 
>           =====+==================================================== 
>                | Out of scope for the SPEERMINT Working Group 
>                | 
>                | <--- Lookup of A and AAAA in DNS 
>                | 
>           IP address 
>                | 
>                | <--- Routing protocols, ARP [14] etc. 
>                | 
>           MAC-address 
>
>                  Figure 1: Session Interconnect Context 

What about:

           INPUT: E.164 number
                | 
                | ENUM lookup of NAPTR in Domain Name System (DNS) 
                | 
                | ENUM Working Group Scope 
           =====+=== INPUT/OUTPUT: SIP URI/AoR ======================== 
                | SPEERMINT Working Group Scope 
                | 
                | Federation Detection, Peer Discovery, Policy Lookup.
                | 
                | -> Determination which SSP to hand to call to
                | 
                | Service Location lookup to derive details of the
                | peering: Addressing and session establishment.
                | 
                | SPEERMINT Working Group Scope 
           =====+=== I/O: Session Establishment Data (SED)  ========== 
                | Out of scope for the SPEERMINT Working Group 
                | 
                | Lookup of SRV/A and AAAA in DNS (RFC 3263)
                | 
                | SIP message generation.         (RFC 3261)
                | IP Routing
                | 

>   Note that in Figure 1, Session Establishment Data (SED), is the data 
>   used to route a call to the called domain's ingress point (see 
>   Section 3.3 for additional detail). 
>

>   As illustrated in Figure 1, the ENUM Working Group is primarily 
>   concerned with the acquisition of SED while the SPEERMINT Working 
>   Group is focused on the use of such SED in routing session signaling 
>   requests. Importantly, the SED can be derived from ENUM (i.e., an 
>   E.164 DNS entry) or via any other mechanism available to theuser. 

Again: this does not match the definition of SED. Proposed change:

   As illustrated in Figure 1, the ENUM Working Group is primarily
   concerned with the acquisition of SIP URI while the SPEERMINT Working
   Group is focused on determing the Session Establishment Data (SED)
   needed to the send a SIP message to a suitable next hop (on the SIP
   layer). The ENUM step (the translation from E.164 number to SIP
   URI) is optional if the user entered a SIP AoR directly as his call
   target.

>   Finally, note that the term "call" is being used here in the most 
>   general sense, i.e., call routing and session routing are used 
>   interchangeably. 
>
>3. General Definitions 
>
>
>3.3. Session Establishment Data 
>
>   Session Establishment Data, or SED, is the data used to route a call 
>   to the called domain's ingress point. A domain's ingress point can be 
>   thought of as the location pointed to by the SRV record [1] that 
>   resulted from the resolution of the SED (i.e., a SIP URI). 

brr.

What about

                                         A domain's ingress point is
   the SBE which will accept incoming calls from the originating SSP.
   
> 
>   More specifically, the SED is the set of parameters that the outgoing 
>   SBEs need to complete the call, and may include: 
>
>     . A destination SIP URI 
>
>     . A SIP proxy to send the INVITE to, including 
>
>          o  Fully Qualified Domain Name (FQDN) 
>
>          o  Port 
>
>          o  Transport Protocol (UDP/TCP/TLS [9/10/11]) 
>
>     . Security Parameters, including 
>
>          o  TLS certificate to use 
>
>          o  TLS certificate to expect 
>
>          o  TLS certificate verification setting 
>
>     . Optional resource control parameters such as 
>
>          o  Limits on the total number of calls to a peer 
>
>          o  Limits on SIP transactions/second 
>
>          o  Limits on the total amount of bandwidth used on a peering 
>             link 
>
>          o  In addition, lower layer parameters (such as Differentiated 
>             Services Code Point (DSCP) [8] markings on SIP and/or media 
>             packets) might also be included. 

Perhaps one need to point out that the SED which carrier A uses to talk
to carrier B does not need to be equal to the SED that carrier C uses
when talking to B.

>
>3.4. Call Routing 
>
>   Call routing is the set of processes, rules, and SED used to route a 
>   call to its proper (SIP) destination.  More generally, call routing 
>   can be thought of as the set of processes, rules and SED which are 
>   used to route a real-time session to its termination point. 

Please strike SED from this paragraph.

>4.2.1. Direct Peering 
>4.2.2. Indirect Peering 
>4.2.3. Assisted Peering 
>4.2.4. On-demand Peering 
>4.2.5. Static Peering 

These definition are good. Perhaps add a paragraph like this:

   The concepts direct/indirect, assisted/not-assisted, and on-demand/statis
   are orthogonal to each other. All eight combinations are possible.

>
>4.3. Functions 
>
>   The following are terms associated with the functions required for 
>   peering. 
>
>4.3.1. Look-Up Function 
>
>   The Look-Up Function (LUF) provides a mechanism for querying an 
>   internal and/or external database, which maintains a list of SIP user 
>   names and associated peering domains. 

"user names"?

This reeks of number-based lookups via the back-door of encoding
them in the username part of SIP URIs. I don't like this.

>4.3.2. Location Function 
>
>   The Location Function (LF) develops call routing data (CRD) by 
>   discovering the Signaling Function (SF), and SF's reachable host (IP 
>   Address and port). 

Didn't we replace CRD with SED?

>4.3.3. Signaling Function 
>
>   The SF performs routing of SIP messages, to optionally perform 
>   termination and re-initiation of the call, and to assist in the 
>   discovery/exchange of parameters to be used by the Media Function 
>   (MF). 
>
>4.3.4. Media Function 
>
>   The MF performs media related functions such as media transcoding and 
>   media security implementation between two SSPs. 

IMHO these two are obsolete. Isn't SF replaced by SDE and MF by DBE?

>5. Federations 
>     Finally, note that a SSP can be a member of 
>
>          o  No federation (e.g., the SSP has only bilateral peering 
>             agreements) 

I still think that  bilateral peerings are special cases of federations
(i.e. one with exactly two members), but I don't insist on that.

HTH,

/ol

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 Sep 2007 10:51:33 +0100

Sorry for lateness - I am just catching up after a period of absence. If
it is not too late:

1) "Finally, the terms "peering" and "interconnect" are used 
   interchangeably throughout this document. " 
Why use two terms for the same thing?

2) "2.  SPEERMINT Context"
Whilst the information in this section seems to reflect the scope of the
SPEERMINT WG, is this appropriate information for an RFC, which will
still exist long after the WG has closed down. If SPEERMINT were used as
the name of a concept, rather than as the name of the WG, this would
satisfy this concern. Likewise, is it appropriate to mention the ENUM
WG? Perhaps we need to go through and remove all references to "working
group".

3) "Call routing is based on the resulting SIP URI."
This should say request routing. Even if the focus of the document is on
VoIP, there are mid-call (mid-dialog) requests too, as well as requests
outside the context of a dialog such as REFER that can also have some
relationship to VoIP.

4) "Such an SBE is "
What type of SBE is this? What other types of SBE are there? Should it
say simply "An SBE is "?

5) "A domain's ingress point can be 
   thought of as the location pointed to by the SRV record [1] that 
   resulted from the resolution of the SED (i.e., a SIP URI)."
What exactly is "i.e., a SIP URI" referring to here? Is it referring to
the SED? Or is it referring to the SRV record. Neither is correct, since
neither is a SIP URI as such (although a SIP URI is part of the SED).

6) The SED is said to include "A SIP proxy to send the INVITE to". Yet
earlier it seems to say that the SED is input to the SRV process, but it
is only after the SRV process has been performed that we have a SIP
proxy to which to send the request.

7) The SED is also said to include "TLS certificate to expect". Again,
if the SED is input to the SRV process, how can the certificate to
expect be known at this stage? The certificate to expect (or rather a
SubjectAltName to expect in the received certificate) can only be known
after performing the SRV process.

8) "Limits on the total number of calls to a peer".
Is this call initiations per second or calls in progress?

9) "Limits on the total amount of bandwidth used on a peering 
             link "
Is this signalling bandwidth, and if so how is this calculated? I assume
it cannot have anything to do with media bandwidth, since that seems to
be outside the scope of SPEERMINT (see Introduction, which talks about
interconnection between SIP servers). Media will flow over different
routes, and not necessarily the route between SIP servers. Also the
amount of bandwidth required for media may not be known at the time of
the INVITE request, since there the SDP answer has not been received
(maybe even no SDP offer has been sent) and in any case bandwidth can
change during a session.

10) "In addition, lower layer parameters (such as Differentiated 
             Services Code Point (DSCP) [8] markings on SIP and/or media

             packets) might also be included."
Again, aren't media packets outside the scope?

11) "3.4. Call Routing 

   Call routing is the set of processes, rules, and SED used to route a 
   call to its proper (SIP) destination.  More generally, call routing 
   can be thought of as the set of processes, rules and SED which are 
   used to route a real-time session to its termination point."
Are we really only concerned with call routing (INVITE requests) or with
any requests?

12) "This document defines a peer network as the set of SIP user agent 
   servers (UASs) [2] and SIP user agent clients (UACs) [2] (customers)"
A UA acts either as a UAC or as a UAS on a per transaction basis, i.e.,
only on a transient basis. It would be better to say "This document
defines a peer network as a set of SIP user agents (UAs) [2]"

13) "as long as they are also reachable via 
   some IP path."
I would prefer to say "as long as the are reachable via a SIP UA".

14) "3.8. Service Provider 

   A Service Provider (or SP) is defined to be an entity that provides 
   layer 3 (IP) transport of SIP signaling and media packets.  An 
   example of this may be an Internet Service Provider (ISP)."
This at first glance is reasonable, but then the next section goes on to
define a SIP Service Provider as something that is not a special case of
a Service Provider, since it operates at layer 5, not at layer 3. We
should perhaps find a different term for "Service Provider" when we mean
layer 3, e.g., "Network Service Provider".

15) "A SIP Service Provider (or SSP) is an entity that provides 
   application level transport of SIP signaling to its customers." 
Elsewhere the document talks about level 5 peering, but now it talks
about application level. Also, isn't it more than just transport. I
don't have a particular proposal, but I don't really like the present
definition.

16) "3.10. Internet Telephony Service Provider 

   An Internet Telephony Service Provider, or ITSP, is a synonym for 
   SSP. While the terms ITSP and SSP are frequently used 
   interchangeably, the SPEERMINT working group uses the term SSP."
So why define the term if we are not going to use it? We could mention
it in a note below the definition of SSP, if really needed.

17) "An alternate, perhaps more operational definition of layer 3
peering 
   is that two peers exchange only customer routes, and hence any 
   traffic between peers terminates on one of the peer's network."
I don't understand this - why does traffic have to terminate on one of
the peers' networks?

18) "4.2.4. On-demand Peering 
   Service providers are said to peer on-demand "
and 
"4.2.5. Static Peering 
   Service providers are said to peer statically "
Since the term "service provider" is defined as relating to layer 3
peering, should we use "SIP service provider" instead?

19) "a real-time transaction (like a SIP message) "
and
"any real-time 
   transactions (like a SIP message)"
Why not just say "a SIP transaction" or "any SIP transactions", since we
are talking only about SIP service providers here, aren't we?

20) In 4.3.1 "SIP user 
   names"
What are "SIP user names"? SIP URIs?

21) "The Location Function (LF) develops call routing data (CRD)"
CRD is not defined anywhere.

22) "by 
   discovering the Signaling Function (SF), and SF's reachable host (IP 
   Address and port)."
Should this say "a peer SSP's Signaling Function(SF)". Or even simplify
by saying "...by discovering a reachable host (IP address and port) for
a peer SSP's Signaling Function (SF)".

23) "The SF performs routing of SIP messages, to optionally perform 
   termination and re-initiation of the call,"
First, we should stick to talking about SIP messages or requests, not
calls. Also I don't see the relevance or meaning of "termination or
re-initiation of the call".

24) "9. Normative References"
How many of these references are really normative? In fact there is no
RFC 2119 language in the document, so are any of the references
normative? Or perhaps the ones that import definitions from other RFCs
(e.g., UA from RFC 3261) can be considered normative, but are all of
them normative, e.g., [14]?

John

> Sent: 04 September 2007 15:32
> To: [email-masked]
> Cc: Malas, Daryl; Peterson, Jon
> September

---

From: Daryl Malas <[email-masked]>
Date: Wed, 26 Sep 2007 09:50:05 -0600

John,

No problem.  I will review yours and Otmar's comments and respond soon,
hopefully. ;-)  Thank you for the feedback.

--Daryl

---

From: Daryl Malas <[email-masked]>
Date: Wed, 26 Sep 2007 12:16:29 -0600

Comments in-line...(all comments are based on either my contributions,
or my assumptions of David's intentions through his contribution --
David, feel free to correct as necessary.)

Great feedback, thanks.

--Daryl

> Why use two terms for the same thing?
IMO..."John ran fast and sprinted to the finish line."  In this sentence
both terms "ran" and "sprinted" imply going fast to the finish line;
however, they are used to provide greater clarity around exactly what
John did.  A writer could have easliy said, "John ran fast to the finish
line."  Which one is better?  I think that's an opinion of the reader.  

I think the intention is the same by using both of these terms
throughout this document.  By using both terms in varying contexts, it
provides greater clarity around the overall "peering" purpose.  

(Sorry...for the poor example, but I was trying to find away to put into
words my view of this.)
> WG? Perhaps we need to go through and remove all references to "working
I think I had heard this assertion before (perhaps by you), and I would
tend to agree.  I think we can reference SPEERMINT and ENUM, but we
should probably eliminate the reference in regards to the working
groups.  I'll review and see what I can do.  I'd appreciate other's
thoughts on how this has been dealt with in other drafts/wg's.
> outside the context of a dialog such as REFER that can also have some
Agreed
> What type of SBE is this? What other types of SBE are there? Should it
Agreed
> neither is a SIP URI as such (although a SIP URI is part of the SED).
Agreed...will correct.
> proxy to which to send the request.
I believe the intention is to describe the SED as encompassing the SRV
process.
> after performing the SRV process.
See previous comment.
> Is this call initiations per second or calls in progress?
Could be either...
> (maybe even no SDP offer has been sent) and in any case bandwidth can
Hmmm...the term "media" is used often throughout this document, so I
don't think we can exclude the concept from the scope of SPEERMINT as an
aspect of what is setup through "layer 5" peering.  I think the
introduction should be updated to indicate media is potentially setup,
but the definition of what encompasses "media" is out of the scope of
SPEERMINT.
> Again, aren't media packets outside the scope?
You can prioritize signaling and media (see previous comment).
> Are we really only concerned with call routing (INVITE requests) or with
The purpose of SPEERMINT was first to address the VoIP aspects of
peering and then potentially provide extensions to encompass other uses
of SIP at a later time.  See charter statement: "The most focused
deliverables of SPEERMINT are best current practices regarding exchange
of real-time sessions among VoIP and other real-time application service
providers and, in particular, how such calls are routed."
> defines a peer network as a set of SIP user agents (UAs) [2]"
IMO...I tend to make it more granular to avoid any confusion.
Generalities are a perfect target in IETF WG sessions.
> I would prefer to say "as long as the are reachable via a SIP UA".
Agreed.

> layer 3, e.g., "Network Service Provider".
That's fine with me....although terms like this are ambiguous.  I think
we had specified Internet Service Provider before, but there were
arguments against being that "specific".  So, we generalized the term
and just provided it as an example.  
> don't have a particular proposal, but I don't really like the present

Hmmm...I'll see if I can think of something to make this clearer.
Anyone else have an opinion (heh...that's a stupid question.  Everyone
has an opinion, right?!)? :-)
> it in a note below the definition of SSP, if really needed.
....don't care either way...we can do that to.  Does it significantly
make things simpler by doing as you suggest?

> I don't understand this - why does traffic have to terminate on one of
IMO, because it occurs in the context of "peering".  Perhaps I'm not
understanding your point here, sorry.
> peering, should we use "SIP service provider" instead?
Agreed.
> are talking only about SIP service providers here, aren't we?
Agreed.
> What are "SIP user names"? SIP URIs?
A user name and domain make up a SIP URI...that's why they are both
specified.
> CRD is not defined anywhere.
"Call Routing" is defined in section 3.4.

> a peer SSP's Signaling Function (SF)".
That's fine...agreed.
> re-initiation of the call".
IMO, the intention here is to indicate re-INVITEs or BYEs are also
handled by the SF.
> them normative, e.g., [14]?
I don't know...I'll have to research this further.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 27 Sep 2007 09:29:11 +0100

Daryl,

Thanks for considering my comments. More below on some of them.

John 

> (Sorry...for the poor example, but I was trying to find away 
[JRE] It can provide greater clarity only if there is a difference
(perhaps only a subtle difference) between the two terms, and then each
term would need to be defined. Also by using two different terms in this
document it encourages other SPEERMINT documents to use two different
terms, so we should avoid it unless there is a good reason.

...
> I believe the intention is to describe the SED as encompassing the SRV
[JRE] You mean the data prior to SRV look-up plus the data available
after SRV look-up? Well, if that's the case, we would need to be very
careful how we use the term. The earlier statement about SED being input
to the SRV process would need clarifying to say that it is only the SED
available at that stage that is input to the SRV process. Or in fact,
isn't it just the domain name and transport, so perhaps we don't need to
refer to it as SED in that particular case.

... 
> > Is this call initiations per second or calls in progress?
[JRE] OK, but should clarify this.

> but the definition of what encompasses "media" is out of the scope of
[JRE] That may help. Nevertheless, the concept of "bandwidth used on a
peering link" seems wrong, because a peering link is between two SIP
service providers (or more specifically between two SFs), and in general
media takes a different path. By the say, the term "peering link" is
used here - I think this is the only place - it is not defined.

> You can prioritize signaling and media (see previous comment).
[JRE] The point is, how would DSCP markings for media be used? It is
fine for an SSP to have an opinion on what DSCP value should be used for
media, but how does it signal to the UA to tell it to use that value?
What if different SSPs involved in a call have different opinions on
which DSCP value to use? I don't like mentioning things when their
relevance or use is not clear.

> providers and, in particular, how such calls are routed."
[JRE] I consider call routing to be the routing of the initial INVITE
request. However, to support VoIP we must also support other requests,
including mid-dialog requests (re-INVITE, UPDATE, BYE, ACK, REFER, etc.)
as well as requests outside the context of a dialog that can still have
relevance to calls (I am thinking particularly of a REFER request sent
outside the context of a dialog, instructing the recipient to initiate
some call-related request such as INVITE).

> Generalities are a perfect target in IETF WG sessions.
[JRE] But my point is a UA is never purely a UAC or a UAS - it combines
both capabilities. During a transaction it initiates it is a UAC, during
a transaction it receives it is a UAS, sometimes it is both at the same
time and most of the time it is neither. But all the time it is a UA.
Even with respect to a single call, a UA can perform both functions,
e.g., it can be a UAC for the initial INVITE request but a UAS for a BYE
or re-INVITE request initiated by the peer UA. So keep it simple.

...
> and just provided it as an example.  
[JRE] I think we have to do something. The term SP is OK if it is
intended to embrace all types of SP that we are dealing with, including
SSP. But if we need a term for an SP that operates only at layer 3, we
need a different term.

> make things simpler by doing as you suggest?
[JRE] The point is, by having an explicit definition of ITSP, it tends
to encourage other SPEERMINT documents to use it, even though there is
an explicit statement that SPEERMINT will use only SSP. I thought just
making it a note below the definition of SSP would help to de-emphasise
ITSP further.

> understanding your point here, sorry.
[JRE] The point is, with indirect peering the next peer might not
terminate the traffic.

...
> A user name and domain make up a SIP URI...that's why they are both
[JRE] It is not "user name" but "userinfo" in the definition of a
SIP/SIPS URI. This would give me a severe problem with the definition:
"The Look-Up Function (LUF) provides a mechanism for querying an 
   internal and/or external database, which maintains a list of SIP user

   names and associated peering domains."
The userinfo part should not be used in the look-up. Assuming the domain
in the host part of the SIP/SIPS URI has not been reached, the userinfo
part should not be taken into account - only the host part should be
used for the look-up. One domain cannot and should not be expected to
have any knowledge of users in a different domain.

> "Call Routing" is defined in section 3.4.
[JRE] Yes, but it doesn't define CRD. It mentions SED - what is the
difference between SED and CRD?

...
> IMO, the intention here is to indicate re-INVITEs or BYEs are also
[JRE] So can't we say "The SF performs routing of SIP requests for
establishing and maintaining calls..."?