Subject: [Sipping] How to indicate trunk groups in URI?

From: "Cullen Jennings" <[email-masked]>
Date: Wed, 21 Aug 2002 11:38:33 -0700

In a tel URL (or the SIP conversion of it) a carrier identification code can
be done with a tag like "cic=+1-0288". Does anyone see any issues with
indicating trunk groups with a tag something like "tgrp=trunk_group_label"?
Better ideas on how to do this?

Thanks, Cullen

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 26 Aug 2002 09:15:09 -0500

Cullen Jennings wrote:
> In a tel URL (or the SIP conversion of it) a carrier identification code 
> can be done with a tag like "cic=+1-0288". Does anyone see any issues 
> with indicating trunk groups with a tag something like 
> "tgrp=trunk_group_label"? 

Glad you bought it up.  I have hit upon this issue as well, and I don't
believe that there is any standardized manner of doing this; i.e. there
isn't any standard R-URI parameter to carry the trunk group.

I have encountered some gateways that expect "dtg=trunk_group_label",
while others need "tg=trunk_group_label".  So much so that we made
the name of the parameter a configuration option in our proxy.  But that
does not help when, over a period of time, requests travel downstream to
N gateways, each from a different vendor, each expecting something
distinct in the downstream R-URI to indicate a trunk group.

 > Better ideas on how to do this?

I don't have a better idea on how to do this; just that it'll be good
to have one.

Options include:

    0) Do nothing
    1) Standardize the name of the R-URI parameter for a trunk group
    2) Come up with a new header
    3) Append it to the To tag (since the dialog will presumably
       terminate at the gateway, which will send out a 200 OK, it could
       first extract the token on the To tag, use that as a trunk
       group, and then generate a new tag for the 200 OK.  This is bad
       since proxies should not be mucking around with To tags on
       requests proxied downstream.)
    4) <Any others that I may have missed>

Options 0, 2, and 3 are no-ops, I think.  That leaves us with option
1 and 4.

If there is any consensus for 1), maybe Cullen and I can create an I-D
to start off a structured discussion...

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 26 Aug 2002 09:56:05 -0500

I vote for 

>1) Standardize the name of the R-URI parameter for a trunk group

Thanks, Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Vijay K. Gurbani
> Sent: Monday, August 26, 2002 9:15 AM
> To: Cullen Jennings
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; Jon 
> Peterson; [email-masked]
> Subject: Re: [Sipping] How to indicate trunk groups in URI?
> 
> 
> Cullen Jennings wrote:
> Glad you bought it up.  I have hit upon this issue as well, 
> and I don't believe that there is any standardized manner of 
> doing this; i.e. there isn't any standard R-URI parameter to 
> carry the trunk group.
> 
> I have encountered some gateways that expect 
> "dtg=trunk_group_label", while others need 
> "tg=trunk_group_label".  So much so that we made the name of 
> the parameter a configuration option in our proxy.  But that 
> does not help when, over a period of time, requests travel 
> downstream to N gateways, each from a different vendor, each 
> expecting something distinct in the downstream R-URI to 
> indicate a trunk group.
> 
> I don't have a better idea on how to do this; just that it'll 
> be good to have one.
> 
> Options include:
> 
>     0) Do nothing
> Options 0, 2, and 3 are no-ops, I think.  That leaves us with 
> option 1 and 4.
> 
> If there is any consensus for 1), maybe Cullen and I can 
> create an I-D to start off a structured discussion...
> 
> Regards,
> 
> - vijay
> -- 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>