Subject: [Iptel] comments on trunk-group doc

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Dec 2005 07:56:09 -0500

Well, first I have to apologize for the tardiness of these comments. I 
promised them ages ago and finally dedicated some time today to iptel 
matters and so got around to this.

Unfortunately I have many substantive comments on the document, see below:

> referred to as "trunks") between Time Division Multiplexed (TDM)
>    circuit switches.  In large switches, a group of trunks that connects

connect

> vendor.  Absent such guidelines, inter-operability will suffer as a
>    proxy vendor must conform to the expectations of a gateway as to

interoperability

>  The trunk group information can be carried in either the "sip" URI or
>    the "tel" URI.  Since trunks groups are intimately associated with

trunk groups

> 4.  Requirements and rationale

you should at least provide some introductory text here, saying that 
this section overviews some of the motivations for the design decisions 
that went into the development of the spec.
> anyway).  Furthermore, using the tel URL also allows this format to
>    be reused by non-SIP VoIP protocols (which could include anything

tel URI, not URL

> normative procedures of Section 19.1.6 of [3] can be used to derive
>    an equivalent "sip" URI from a "tel" URI, complete with the trunk

here, you put the URI schemes in quotes, whereas this wasnt done before. 
Leave unquoted.

>  respectively, signifies the intent.  A proxy (or any other
>    intermediary -- see next section) MAY insert a trunk group appears in
>    the R-URI; to the next downstream entity this signifies an egress (or
>    terminating) trunk group to be used.

this section is really informative and shouldn't have any normative 
statements in it like this. Also, the sentence doesn't make sense, looks 
like "appears" is extraneous. Suggest:

A trunk group parameter in the request URI is an indication from a SIP 
entity (for example, a proxy) to the next downstream entity that a 
specific egress trunk group should be used.

> To the processing User Agent Server (UAS), a trunk group in the R-URI
>    implies that it should use the named trunk group for the outbound
>    call.  If a UAS supports trunk groups but is not configured with the
>    particular trunk group identified in the R-URI, it SHOULD not use any
>    other trunk group other than the one requested.

more normative text in a requirements section. Actually, this is pretty 
fundamental processing steps here. My suggestion is to create a seperate 
section, called "Client Behavior" (using client in the sip transaction 
sense), which describes rules by which any entity acting as a sip client 
can insert a tg parameter in the R-uri, and another section on Server 
Behavior, that discusses treatment on receipt. Then, make this section 4 
entirely informative and move it below. As written now it is very 
confusing about what this is.

Also, in terms of the specific normative strength here, this is a 
SHOULD. What would be the conditions by which you would ignore that tg 
parameter and send it elsewhere? Seems like ignoring it could cause 
interop problems.

>  A User Agent Client (UAC) that initiates a call and supports this
>    specification MAY include the trunk group in the Contact header.  If
>    it does so, the trunk group in the Contact header represents the
>    originating trunk group.  Subsequent requests destined to that UAC
>    MUST copy the trunk group from the Contact header into the R-URI.

this is confusing. I think you are referring to mid-dialog reuqests, 
which will, as a consequence of rfc3261 processing, result in the 
contact appearing in the r-uri. If so, there is no need to re-specify 
rfc3261 behavior. I'll also note that this won't happen for non-dialog 
requests like MESSAGE, which can come through a pstn gateway (SMS to 
SIP), and can have a trunk group in the contact, so this text is not 
really accurate anyway.

> Among other sources of request arrival (not shown in Figure) at the
>    proxy is GW1.

I found this sentence confusing; GW1 is shown in the figure. "Not shown" 
apparently refers to other sources. But, they're not relevant anyway, so 
why mention it?

> GW1 in Figure 1 is always cognizant of any requests that arrive over
>    trunk group TG1-1.  If it wishes to propagate the ingress trunk group
>    to the proxy, it MUST arrange for the trunk group to appear in the
>    Contact header of the SIP request destined to the proxy.  

here too, normative statements seem out of scope for a section on 
reference architecture; these need to be collected into a section on 
behaviors of clients and servers.

> the proxy MUST arrange for the trunk group to appear in the
>    SIP R-URI of the request destined to that gateway.

as above

>   [2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
>         Specifications: ABNF", RFC 2234, November 1997.

update to 4234

>   trunk-group-label = *1( unreserved / escaped /
>                             trunk-group-unreserved )

shouldn't this be 1* and not *1

>   trunk-group-unreserved is the intersection of param-unreserved
>       defined in [4] and user-unreserved defined in [3].  Since the

There is no user-unreserved defined in the grammar. unreserved and 
escaped are used; you need to say where those are defined. unreserved is 
actually in BOTH 3966 and 3261 it seems; though thankfully they appear 
to be the same definition.

>  Since the
>       trunk group is an extension to the tel URI and will end up as the
>       user portion of a SIP URI, the ABNF for it has to ensure that it
>       can be adequately represented in both the constructs.
>       descriptor is defined in [4].

Hmm. This should not be needed. Note the grammar for the SIP URI:

SIP-URI          =  "sip:" [ userinfo ] hostport
                     uri-parameters [ headers ]
userinfo         =  ( user / telephone-subscriber ) [ ":" password ] "@"

note that userinfo can contain telephone-subscriber directly. That, 
through further definition, includes the extension characters for the 
tel URI. Thus, there is no need to perform this intersection as you have 
done. If it was needed, it would have been a bug in 3966.

>   If the receiver of a SIP request is not the owner of the domain (or
>    global prefix) specified in the "trunk-context", it MUST treat the
>    trunk group as if it was not there.

It is my understanding that normally trunk group identifiers are scoped 
to the switch to which they are attached. That is, two switches in the 
same network can both use the same identifier. If so, the usage of 
descriptor as a scoping tool is a little odd; descriptor is meant to 
provide a scope for service providers or countries, where numbering 
plans are scoped. You could use a descriptor to define a switch, if you 
used a domain name equal to the host name of the machine, i.e., 
gw22.provider.net. But the phone number prefix would never be useful.

So, if I am correct and trunk group identifiers are in fact scoped to a 
switch/gateway, this requires further discussion in the document at least.

Another point on this text. Its not actually clear what it means to 
"treat the trunk group as if it were not there". What is the meaining of 
"trunk group" in this sentence? Do you mean the two URI parameters 
(i.e., ignore tgrp and trunk-context)? I would think that, if a gateway 
receives a request targeted to a trunk group that doesnt exist, its akin 
to get a request with a domain name that doesn't match your own, and you 
would reject with 404.

> F1:
>    INVITE sip:[email-masked]
>    ...
>    Contact: <sip:4554;phone-context=example.com;tgrp=TG1-1;
>       trunk-context=[email-masked]>

Well, I'll first quote draft-ietf-sip-guidelines here:

  For an example of how to construct a good examples section, see the
    message flows and message formatting defined in the Basic Call Flows
    specification [21].  Note that complete messages SHOULD be used.  Be

which says that you should use complete messages. The messages here are 
not only incomplete, they are gramatically wrong even for the pieces 
they show. Note the missing SIP/2.0 in the r-uri. The URI in the R-URI 
also omits user=phone which probably should be there.

> reached GW1.  Under normal circumstances (i.e., instances where the
>    calling party number is present in signaling), GW1 would derive a sip
>    URI to insert into the Contact header.  This sip URI may contain, as
>    its user portion, the calling party number from from the incoming SS7
>    signaling information.  The trunk group information then becomes part
>    of the user portion as discussed previously.

this is really an implementation choice; I actually don't think that 
this is that common. YMMV. Anyway, I think its important to point out 
that putting the phone number in the user part of the contact is 
optional and an implementation choice anyway. As such, the whole bit 
about handling incoming calls without a calling number is merely a 
statement of the obvious - your local implementation can put in whatever 
it wants, but obviously not the information thats not there...

> Once the request is in the domain of example.net, the namespace
>    imposed by the "trunk-context" parameter in the Contact header
>    prevents collisions with similiar trunk groups maintained by the
>    example.net domain.

this doesn't make sense. The contact in the invite is not used by the 
recipient in any way except to get the request routed back the 
originator, which uses the domain part of the SIP URI. The user part of 
the contact is only ever looked at by the entity that inserted it, so 
consequently namespace collisions are not an issue.

The main use for the namespace scoping is really in the r-uri, I think, 
to make sure that a request goes to a trunk group on the gateway that 
houses it. Largely to deal with configuration problems.

> 8.  Security considerations
> 
>    The extension defined in this document does not add any additional
>    security concerns beyond those already enumerated in [3].  

I disagree. Consider this; modifying the r-uri in a request in-transit 
would allow me to cause the gateway to use one specific trunk group over 
another. I can launch all kinds of nice attacks by making gateways use 
the wrong trunk group. For example, a service provider gets charged when 
they route inter-lata traffic over a local trunk. Or, there might be a 
toll-free trunk that I can force calls on and get free calls or 
something. Thus, integrity of this thing is important.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 Dec 2005 09:32:00 -0600

Jonathan:

This is an ACK for the comments on trunk-group and tel-reg.
Thanks for the detailed review of both.

I'll follow-up with any ensuing discussions on the list,
followed by revisions of both the docs.

Thanks,

- vijay