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