Re: [Iptel] Is trunk group a new namespace?

[Cullen Jennings <[e-mail]>]

inline comments - not as chair..

Summary - I am very against the new URI type idea. It is not deployable -
more inline

On 1/13/05 3:06 PM, "Vijay K. Gurbani" <[e-mail]> wrote:

> Folks,
> 
> In order to close the last open issue with trunk-group, I had
> a series of email exchanges with the WG chairs, the
> results of which now need to go before the WG to decide how to
> move forward.
> 
> The last open issue was how to resolve the case where an
> incoming call request does not have a calling party's number
> available.  How do we indicate the originating trunk group?
> 
> We had almost reached a solution in the form of the following
> URI: Contact: <sip:telurifmt;tgrp=[e-mail]> (the
> I-D exhorts originating trunk groups to go in the Contact
> header).
>

I don't like the making up telurifmt as a special SIP user name. However,
what the user port of a contact is is a GW local issue and not defined by
SIP. The GW could put line1 or ds0-22 or a random number. This problem only
comes up in the context of what originating information that is currently in
the contact header.
 
> In the email exchange with the WG chairs, Jonathan has
> suggested a couple of issues: first, the fact that a trunk
> group can exist without a phone number appears to imply that
> it is cannot be associated with a tel URI and may, in fact,
> indicate that this is a new resource complete with its
> own scheme.  Something like:
> 
>     trgrp:trunk-group-id[:phone-number]@domain

The trunk group without a phone number would clearly be useless as a
destination. As a GW source information, I'm not keen on it. Were would you
put it? In the Contact header? You would have to map it to a sip URI to do
this which would result in a SIP uri in the contact that looks almost
identical to what everyone has already implemented. This would be a huge
amount of work that in the end resulted in protocol on the wire that was
semantically identical and differed by at most a few bits in syntax.

I am really against the new URI type idea - many SIP elements support tel
and the current proposal works in a backwards compatible way with all those
devices. If we make a new trgrp URI, no proxy or UA will know about it or be
able to do anything with it. There is no migration path from tel to trgrp
until they are all replaced. No one will every do it because they are
already using tel. 

> 
> Second, saving the originating trunk group in the Contact
> header is not semantically correct; if the originating trunk
> group is to be used for routing, then Contact is not the
> semantically correct header to save this information in.
>

I'm not sure I agree with this. The Contact identifies the resource on the
UA. The trunk group is part of the resource name on the GW. Saying you can
only route on things in the request URI it totally bogus. I'll point at CPL
for example. It is fine to route on many things in the SIP message. The
contact header, as used in a registration if pretty fundamental to how
requests get routed in SIP. GRU is going to work because some elements are
going to look at tag in the contact and route based on them.

 > Here is my take on these issues.  The second one is easier
> to tackle, so let me try that first.  Jonathan is accurate
> in pointing out the semantic use of Contact header.  How-
> ever, we reached a decision long time ago in the life of
> the trunk-group I-D that we would like NOT to have parameters
> like ;o-tgrp=xxx;t-tgrp=yyy in the R-URI.  Hence we
> decided to put the originating trunk group in the Contact
> header with the understanding that when it is used for
> routing in the reverse side, it will appear in the R-URI
> position.  But what if it is used in routing on the initiating
> side?
> 
> The first issue -- trunk-group being a new resource --
> is an interesting one.  It has ramificiations, if we decide
> to go that route.  Where will it appear?  In a new header(s)?
> as parameters to the R-URI or the Contact URI?  We will need
> a short paragraph on how to convert trgrp URIs to sip URIs
> or tell URIs, ...
> 
> So, we have some choices to make:
> 
> Regarding putting originating trunk group information: do we
> want to leave it in the Contact header or find a new place
> for it?

I view the originating trunk group as part of the name of the resource on
the GW and thus reasonable to put in the contact.

> 
> Regarding representing trunk group information itself: do we
> want hash out more abstractly the relationship between the
> trunk group and the phone number from a namespace prespective?
> 
> To make matters worse, I will point out that we already have
> a few implementations that are following
> http://www.ietf.org/internet-drafts/draft-ietf-iptel-trunk-group-02.txt.
> So depending on what we decide, the implementations will be impacted.
> 
> Opinions and comments welcome.

If someone can point out the harm that results in trunk group being a
parameter of a tel URI that would be fixed by having a separate namespace, I
would probably change my opinion.

> 
> Thanks,
> 
> - vijay


Part of this discussion was brought up by the example of an IAM with no
originating phone number but where the GW still sends an INVITE. In this
case SIP does nto say what to put in the From but this is a SIP/tel problem
not a trunk group problem.

My proposal .... More or less keep what we have and

Allow a trgp and phone-context parameter in a tel URI.

Also allows these is a SIP uri even if that SIP URI is not mapable to a
valid tel URI

When this is seen in a contact, it identifies the PSTN associated resource
on the GW identified by the contact header

When this is seen in a request URI, it specifies the desired trunk group for
reaching the PSTN resource identified in the request URI

We have been discussing this for a long long time as a WG item. Unless
someone has some specific harm or problem caused by the proposed solutions,
I'm not keen on totally throwing it out.

PS - I'm sick and can't think straight - I lost my crypto token and can't
run my VPN so can't do email so have no idea when I will send this or
receive responses. I reserve the option to claim my evil twin skip wrote
this and I disagree with all of it :-) Someone convince me I'm nuts.







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