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

[Gonzalo Camarillo <[e-mail]>]

Hi,

[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]).
 
> This can be heavily dependant on the individual implementations
> of network nodes without bothering to standardise where the
> information "should" be located. That's the elegance of the
> SIP protocol.
> 
> 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?

We could send a "Require" header in the SIP request indicating that we
are sending ANSI ISUP.
We could answer with an "unsupported" header, since they do not want to
receive ANSI ISUP in Sweden... then, the MGC in the States would send
ITU ISUP, or whatever is understood in Karlstad...

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

Regards,

Gonzalo

>, a proxy server into another vendor's network
> (as in the case of the 44* entry), private exchange gateways
> (like the ericy entry), a redirect server for PSTN calls (like
> the 800 server), and a redirect server (and probably
> registrar) for native sip clients, as in the 1-500 entry.
> I'll describe what I'm thinking of with the default entry
> in a bit.
> 
> If a particular service provider wishes to encapsulate all
> of the routing into a centralised database, they can have
> just a single "default" entry which points to a proxy or
> redirect server in charge of determining a final destination.
> 
> For standard (e.g. PC-based) SIP UAs, you could have a similar
> (more complete, if necessary) routing table in a redirect or
> proxy server which the users are then instructed
> to use. This database would probably also be used as
> an authoritative routing table, to which the gateways
> could "punt" in case their local routing configuration data
> was insufficient.
> 
> So, for the examples I have given so far, a native SIP
> client, in order to place a PSTN call to [phone]
> which is carried and billed by bell.com would use
> "sip:[e-mail]" (which would proxy or redirect them
> to "sip:[e-mail]"); if the user
> wanted to use xyz.com, they would instead enter
> "sip:[e-mail]" (which would proxy or redirect them
> to "sip:[e-mail]").
> 
> To reiterate: the answer to your question is "whatever the
> service providers decide they want to do," since any solution
> will be compatible with any other arbitrary solution (although
> I think the basic architecure I described above has a certain
> elegance).
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: [phone] | 1010 E. Arapaho, MS L-04
> [e-mail]   | Fax: [phone] | Richardson, TX 75081 USA

-- 
Gonzalo Camarillo         Phone :  [phone]
Oy L M Ericsson Ab        Mobile:  [phone]
Telecom R&D               Fax   :  [phone]
FIN-02420 Jorvas          Email :  [e-mail]
Finland