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

[Jonathan Rosenberg <[e-mail]>]

Also not as chair.

I've considered this further, and concluded that here is a case where 
the pragmatic approach in the current draft is probably a better choice 
than the more theoretical considerations that led me to consider the 
idea of a new namespace.

As such, I agree with everything cullen suggests, but disagree on one 
point. Cullen suggests:

 > 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

I'd rather not do that. Instead, I'd rather declare this problem 
(indicating a trunk group without a phone number) as out of scope. This 
is not a tel URI issue at all - its an ISUP to SIP mapping issue. Our 
job is to define a way to extend the tel URI to be able to indicate 
trunk groups, and nothing more.

Thanks,
Jonathan R.

Cullen Jennings wrote:

> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

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