Re: draft-ietf-mmusic-sip-multipart-00.txt

["Adam B. Roach" <[e-mail]>]

Gonzalo Camarillo 
>[e-mail] wrote:
>> >The more interesting question is what should the interaction be between the
>> >"ISUP call model" and the SIP UA in deciding where to send the SIP invites?
>> >For example, who is responsible for locating the terminating MGC (assuming
>> >in this case that the destination is in the PSTN)?  Does the answer depend
>> >on whether the originator is a PSTN terminal or a SIP UA?
>
>The terminating MGC should not depend on the originator... it depends on
>the carrier you want to use (sip:[e-mail] or
>sip:[e-mail]).

In the case of a native SIP terminal, this makes sense. For PSTN
service, you will not typically use an egress gateway owned by
someone other than the ingress gateway, just as I don't currently
have my long distance calls carried half the way by MCI Worldcom, and
the other half of the way by Sprint. 

>> One simple solution for PSTN/SIP gateways would be for each
>> gateway to have a map of which number prefixes should be
>> sent to which destination; e.g.:
>> 
>> number map | destination
>> -----------+------------------------------------
>> 1713*      | pstn-gw.houston.tx.us.bell.com
>> 1218*      | pstn-gw.bemidji.mn.us.bell.com
>> 46054*     | pstn-gw.karlstad.ks.se.bell.com
>> 44*        | sip-proxy.bt.co.uk
>> 1972583*   | pbx-gw.ericy.com
>> 1800555*   | sip-redir.800.bell.com
>> 1500555*   | sip-redir.sip-clients.bell.com
>> default    | bell.com
>> 
>> This allows the gateway owner to either specify which egress
>> gateway (as in the case of the Houston, Bemidji, and Karlstad
>> entries)
>
>Yes, this way we can send the INVITE to the proper destination. But if
>this is a PSTN/SIP gateway in the States, and we end up in Karlstad
>(Sweden), which flavour of ISUP will we send in the SIP body?

The simple answer would be, "none." The Karlstad gateway is already
going to have the capability of creating ISUP messages to allow
native SIP clients to place outgoing calls. 

If transit of ISUP parameters is important for out applications,
and we know how to perform the translations, we could transit 
International ISUP, ITU ISUP, or a local variant of ISUP.

>How do you guys think this negotiation has to take place?

For the above cases, since we're already provisioning information
about the gateways, it could quite easily be part of the same
table (this table assumes we have a super fantastic gateway
that can do arbitrary signalling translations):

number map | destination                        | signalling   | public key
-----------+------------------------------------+--------------+-------------
1713*      | pstn-gw.houston.tx.us.bell.com     | ANSI ISUP    | A246FD87...
1218*      | pstn-gw.bemidji.mn.us.bell.com     | ANSI ISUP    | D6438E75...
46054*     | pstn-gw.karlstad.ks.se.bell.com    | ITU ISUP     | 938EF64A...
322*       | pstn-gw.brussels.be.bell.com       | Belgian ISUP | 3E71F29E...
44*        | sip-proxy.bt.co.uk                 | BT NUP       | 375D17FA...
1972583*   | pbx-gw.ericy.com                   | NONE         | -
1800555*   | sip-redir.800.bell.com             | ANSI ISUP    | E93F2A7E...
1500555*   | sip-redir.sip-clients.bell.com     | NONE         | -
default    | bell.com                           | NONE         | -

Because of regulations in some countries, we will always need to
have the option of blocking ISUP transit to selected destinations;
starting out with the assumption that we can just go ahead and
send out the local varient to see if it gets rejected may land 
operators in legal problems.

-- 
Adam Roach, Ericsson Inc. |  Ph: [phone] | 1010 E. Arapaho, MS L-04
[e-mail]   | Fax: [phone] | Richardson, TX 75081 USA