TRIPGW Update Attributes

Gary Chung Wing <[email protected]> Tue, 25 Jun 2002 15:53:26 -0400
Newsgroups gmane.ietf.iptel
Message-ID <[email protected]>
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.
- 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?
- 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)? How can a GW honour this request with this
combination of route elements?
- 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?

case 2:
	prefix=1617 
	no attribute sent

Should GW select a route only using the prefix as a criteria? 

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.

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


Thanks for the help.
Gary