Subject: RE: [Sipping] SIP-T signaling to manage bilateral agreements

From: Adam Roach <[email-masked]>
Date: Sun, 12 May 2002 13:49:34 -0400

The widely accepted solution for this problem (to my knowledge)
is to use the host name portion of a Request-URI.

For example:

sip:[email-masked]

could well resolve to the same IP address as:

sip:[email-masked]

...and the host portion could be used for signalling the agreements
to which you refer. It's very analogous to multi-homing web servers.

Remember, one of the most important -- no, acutally *the* most
important aspect of the SIP-T specification is that it is
fundamentally compatible with PSTN-unaware SIP devices. The proposals
you offer mean that SIP devices, by choosing arbitrary values for
the parameters from which you want to infer information, will be
unintentionally triggering policy decisions on the gateway. Very bad.

One of the key things about the scheme I describe above is that it
is truly a bilateral agreement that can be done ad-hoc. The databases
you use for PSTN breakout routing are simply provisioned with such
information encoded in the hostname, as I describe above. DNS already
has support for this sort of thing. All you need now is PSTN gateways
which can use the host portion of incoming Request-URIs to make the
sort of policy decisions you talk about. Carriers just need to make
sure they include this in their RFIs to vendors, and they're set. 

A standardized soultion is overkill for any situation that can be
solved without standardization, and I've seen the above solution
deployed in multi-vendor carrier labs without any need for
standardization -- or even inter-vendor coordination -- at all.

That said, an *informational* RFC on the topic might provide
some guidance. Any volunteers? :)

/a

-----Original Message-----
From: Chaney, Charles [mailto:[email-masked]]
Sent: Monday, April 29, 2002 8:01
To: [email-masked]
Subject: [Sipping] SIP-T signaling to manage bilateral agreements

It's likely this has come up before but I can't seem to locate any
information on it:

From the information in <draft-ietf-sipping-isup-01> and RFC 3204, there is
no mention for including the circuit identification code from the ISUP
header in the SIP message body or the encapsulated ISUP since the
encapsulation starts at the message type code. In the PSTN the circuit code
is part of the ISUP message header and its handling is fully standardized.
It is used to not only identify the involved circuit or connection but also
allows assignment of specific handling by the source and destination network
nodes via bilateral agreements. These circuits are typically grouped
together in ranges, a.k.a., Trunk Groups and assigned special handling
properties. For there to be any form of interoperability between networks
(e.g., SIP bridging) support for this is fundamental. 

While there are some options that could be considered, the support must be
agreed (as a standard?) since multi-vendors are likely involved. Some
examples that one might consider for signaling the bilateral agreement
requirements:

- Dedicated SIP Call-Id allocation algorithms, known by the involved
signaling nodes.

- MG SDP (e.g., RTP address and port number) assignment and bilateral
knowledge about this allocation in involved call partner MGC assignments,
SDP.  

- Static assignment at the transport level, e.g., UDP port number could be
associated with a grouping of these circuits if UDP is used. Other transport
support would require further investigation.

- None of the above are proposals at this time, they are only meant to be
examples to further the discussion. Maybe there are others?

Regards,
Chuck Chaney

_______________________________________________
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