Re: TRIPGW Update Attributes

responses inline. Sorry for the delay.

Gary Chung Wing wrote:
> Hello, I need some clarification regarding interpreting the new
> attributes
> sent in the Update.
> 
> Can you confirm/correct my understanding of how to interpret a gateway's
> advertisement for the following. Given an Update advertising a prefix
> address family(say 1671) with 2 types of modifying attributes: carrier
> attribute (cic1 and cic2) and trunk group attribute (tg1 and tg2).  Is
> the
> following correct:
> 
> - there is NO association between the cic and the trunk group attributes
> sent in the Update; i.e. an LS cannot assume that the gateway advertises
> that tg1 is connected to cic1 and tg2 is connected to cic2; or any kind
> of
> relationship between the cic attributes and the tg attributes.

Correct.


> - assuming the attributes are unassociated, the semantics of the message
> states that the gateway can route incoming calls from the IP side for
> the
> given prefix on any of the trunk groups advertised OR through any of the
> cics on the trunk (pstn) side. Is this right?

Yes.


> - assuming that the above is true, and given that the GW advertises as
> above, does it make sense for any signaling hop on the IP side to send a
> signaling message (eg. SIP INV) to this GW, specifying a combination
> Prefix
> Address Family, Carrier attribute, and Trunkgroup attribute (for example
> 16172345678, cic1, tg1)?

Sure.

> How can a GW honour this request with this
> combination of route elements?

Well, its supported according to the advertised route.

> - Again given the GW advertises as described above, what should the GW
> (typically) do to route the call when it receives from a signaling hop
> on
> the IP side a signaling message (eg. SIP INV), as described below:   
> 
> case 1:
> 	prefix=1617  
> 	attribute cic=cic3: 
> 
> Should the GW select a route only using the prefix, discarding the cic?
> or
> should it fail the call since the cic specified in the INVITE cannot be
> satisfied?

This is more of a tel URI issue, as its orthogonal to TRIP. What 
generally does a gateway do when it receives a SIP request with a tel 
URI requesting an unsupported cic? I would argue it probably rejects it 
with a 404.


> 
> case 2:
> 	prefix=1617 
> 	no attribute sent
> 
> Should GW select a route only using the prefix as a criteria? 

If it receives a SIP INVITE like

INVITE sip:[email protected] SIP/2.0

it routes that as best it can. Since no trunk group or cic or anything 
else was specified, it can route it however it likes.


> 
> case 3:
> 	prefix=1905 
> 	cic=cic1
> 
> Should GW fail the call since the address family is prefix and there is
> no
> match on the given prefix or would it simply use the cic to route the
> call.

Same as all of the rest of the above. If the gateway can't complete a 
call to a given URI, it rejects with a 404. This has nothing to do with 
trip.


> 
> - Is there any network topology on the trunk (pstn) side of the GW that
> an
> LS can assume when it receives a TRIPGW Update message as described
> above? 

No.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email protected]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com