Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

["Daniel G. Petrie" <[e-mail]>]

This is a bit of a diversion, at least in application of this technique as this
is a perspective of a call initiated on a IP node.  We have been thinking of
using a simular approach to solving the digit collection issue for SIP user
agents without using time outs, send buttons or requiring the user agent to have
a huge dial plan.

1) a user agent registers with its favorite proxy(s) and in the response gets a
high level dial plan/patterns which correlates patterns with server URLs.  For
example:
911                 -> sip:[e-mail]
9938xxxx        -> sip:<pattern>@local-gateway.mycompany.com
4xxx               -> sip:<pattern>@new-york.mycompany.com
5xxx               -> sip:<pattern>@dallas.mycompany.com
91xxxxxxxxxx -> sip:<pattern>@us-carrier.com
9110x             -> sip:<pattern>@international-carrier.com

2) The user dials digits until the SIP UA matches a pattern and sends an INVITE.

3) At this point the behavior is as Jonathan and Pete suggest:
  The proxy with secondary dialplan knowledge accepts the request as a complete
address or sends back a 484, optionally with second tier pattern(s) and
corresponding server URLs.

It would be great if we can define a framework that solves this problem from
either direction.
Cheers,
Dan



Pete Cordell wrote:

> Jonathan,
>
> I like this solution for handling in-complete numbers.  It would be nice if
> there was some way to reduce the number of failed attempts though.
>
> Perhaps the 484 response could contain a parameter that specified the
> minimum number length for a number of the given pre-fix.
>
> A megaco style digit map could be included, but I feel this is overly
> complicated to expect all UAs to understand it.
>
> Perhaps parameters in the 484 could specify the minimum number of digits
> needed and optionally a digitmap.
>
> That way a simple device could keep trying digit by digit as in your
> example.  An improved device could wait until it had collected the minimum
> number of digits, and the mega super special version could interpret the
> digit map.
>
> (In this I'm assuming that the digit map is a lot easier to generate -
> perhaps using manual or off-line means - than it is to interpret.  If a
> digitmap is manually generated, or uses some off-line process to generate
> it, I'm assuming that all a proxy has to do with it is copy it to the
> appropriate 484 response field.)
>
> The thing I'm not sure about is the handling of the SAMs.  On the face of it
> I would prefer these to be transported through the network rather than being
> re-generated.  I don't know whether the final INVITE should include IAM plus
> all the additional SAMs, or whether it is appropriate to define a SAM that
> captures all the changes from the previous SAMs.  Another option is not to
> send any SAMs at all, but update the IAM with the SAM information.
>
> Pete
>
> =============================================
> Pete Cordell
> [e-mail]
> =============================================
>
> -----Original Message-----
> From: Jonathan Rosenberg <[e-mail]>
> To: Gonzalo Camarillo <[e-mail]>
> Cc: [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>
> Date: 18 November 1999 15:58
> Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt
>
> >What if, rather than encapsulating subsequent digits into INFO, they are
> >added to the request URI in an INVITE? A local proxy for the gateway
> >will respond with 484 to all those that don't have enough digits until
> >it gets one that does have enough. So:
> >
> >
> >Ingress GW            P             Egress GW
> >
> >INV tel:1 ------------>
> >CSeq: 1
> >
> >INV tel:12 ----------->
> >CSeq: 2
> >
> >
> ><---------484 --------
> >          CSeq: 1
> >
> >INV tel:121 --------->
> >CSeq: 3
> >
> ><---------484 -------
> >          CSeq: 2
> >
> >INV tel:1212 --------> ---------------------->   IAM 1212---------->
> >CSeq: 4
> >
> ><--------------484----
> >               CSeq: 3
> >
> >INV tel:12125---------> ----------------------> SAM 5 ------------->
> >CSeq: 5
> >
> >INV tel:121255 -------> ----------------------> SAM 5 ------------->
> >CSeq: 6
> >
> >INV tel:[phone] ------> -----------------------> SAM 5 ------------>
> >CSeq: 7
> >
> >.......(same thing for digits 1, 2, 1)
> >
> >INV tel:[phone]----> ---------------------> SAM 2 -------------->
> >CSeq: 11                                        <---------ACM-------
> >
> >                         <------484-----------
> >                                CSeq: 5
> >                         <------484-----------
> >                                CSeq: 6
> >                               .......
> >                         <------484
> >                                CSeq: 10
> >                         <---183--------------
> >                                CSeq: 11
> >
> >
> >Ok, so let me explain. Proxies do routing just on longest prefix matches
> >for INVITE's. So, proxy P can be stateless actually, as it just forwards
> >INVITEs that match 1212. The ingress gateway sends a re-INVITE (possibly
> >without waiting for a response to the previous INVITE) every time a new
> >digit is received from the PSTN. Once the proxy has enough digits to
> >route, it won't send 484 anymore, and forwards it to the egress gateway.
> >The egress gateway is smart, and creates an IAM from the first INVITE.
> >Subsequent re-INVITEs cause SAMs to be sent, containing the difference
> >in the set of digits from the previous INVITE. Once the egress gateway
> >receives an ACM (address complete, right?), it responds with a 484 to
> >all the INVITEs but the last, and the final INVITE with a 183. Things
> >progress normally from there.
> >
> >Implications:
> >
> >1. proxies don't have to know anything about INFO or ISUP. They just
> >have to know longest prefix match routing for phone numbers. They can
> >even be stateless.
> >
> >2. egress gateways that know ISUP effectively re-generate the SAMs
> >
> >3. if the egress point is not an ISUP gateway, but a PC terminal or
> >something that happens to have a phone number as its name, it will have
> >to know enough to reject each INVITE until it gets one with a request
> >URI/To field that matches its own number. This, BTW, is normal behavior.
> >A UAS rejects an INVITE if the URI is for an address thats not its own.
> >
> >4. This works *even* if there is misordering of re-INVITEs. The egress
> >gateway computes the SAMs based on differentials. So, lets say it
> >receives the INVITE with 1555, then the INVITE with 155512. It then
> >sends two SAMs, the first with 1, the next with 2. Lets say, then, that
> >the INVITE with 15551 comes. Based on CSeq, the egress gateway knows its
> >old and rejects it.
> >
> >5. The ingress gateway doesn't depend on special messages or a
> >completion character, like #, to send an INVITE.
> >
> >
> >
> >
> >Its very possible I've completely missed something, as I'm hardly an
> >ISUP expert. Perhaps there is additional data in SAM such that it MUST
> >be sent across, rather than being regenerated. But, the above solution
> >seems nice, as it doesn't break anything, works with non-ISUP
> >terminating points, doesn't require users to dial a # at the end of the
> >digit string, etc.
> >
> >Comments?
> >
> >-Jonathan R.
> >
> >
> >Gonzalo Camarillo wrote:
> >>
> >> It is nicer to send complete URIs in the "to" header. If the i-gateway
> >> sends the INVITE before receiveing all the digits, the "to" header is
> >> not complete. It would contain just a few digits of the whole telephone
> >> number (this assumes that with just some digits the i-gateway figures
> >> out where to send the INVITE).
> >>
> >> Gonzalo
> >>
> >> [e-mail] wrote:
> >> >
> >> > >The use of a timer to force enbloc signaling is not acceptable. In the
> case
> >> > >of SIP bridging, subscribers originating calls from the PSTN will not
> accept
> >> > >an artificial post-dial delay (even if it is just a few seconds long).
> >> > >Overlap signaling must be supported. It is essential that the overlap
> >> > >process takes place within the context of a single session - using the
> >> > >suggested INVITE/CANCEL/INVITE approach would result in multiple
> abortive
> >> > >calls being delivered to the terminating agent, which would not be
> >> > >acceptable.
> >> > >
> >> > >Why not send an INVITE message when the ISUP IAM is received and then
> send
> >> > >subsequent INFO messages for each ISUP SAM? I understand that "pure"
> SIP
> >> > >agents will expect the INVITE to contain the complete address of the
> called
> >> > >party. This could be handled by including support for overlap in the
> >> > >"Require" extensions
> (draft-roach-mmusic-sip-pstn-require-header-00.txt). If
> >> > >the terminator did not support the PSTN extensions, the originator
> could
> >> > >then switch to enbloc and wait for the full address to be collected.
> >> >
> >> > There are a variety of problems here. The first is determining how
> >> > intervening proxies will react. If, for example, a proxy is making
> >> > decisions about where to forward messages based on a called party URI,
> >> > your suggestion would require it to understand ISUP (for interpretation
> >> > of SAM message). It also requires it to have number analysis code and
> >> > dialing plan information (potentially for the entire globe).
> >> >
> >> > The problem gets even stranger for redirect servers, which expect to
> >> > be able to send an immediate response to an INVITE -- not sit around
> >> > collecting digits.
> >> >
> >> > Basically, your suggestion forces overlapped dialing deep into each
> >> > and every SIP node in the network that is expected to receive calls
> >> > originating from the PSTN network.
> >> >
> >> > I agree that this is a problem that needs to be solved if we intend
> >> > to use SIP between two PSTN phones; but we need to find a better
> >> > solution than tunelling SAMs all over the place.
> >> >
> >> > We shouldn't overlook human factors: it could be that customers are
> >> > willing to, for example, be trained to press "#" at the end of a
> >> > phone number to skip the post-dial-delay.
> >> >
> >> > --
> >> > 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
> >
> >--
> >Jonathan D. Rosenberg                       200 Executive Drive
> >Chief Scientist                             Suite 120
> >dynamicsoft                                 West Orange, NJ 07052
> >[e-mail]                     FAX:   [phone]
> >http://www.cs.columbia.edu/~jdrosen         PHONE: [phone]
> >http://www.dynamicsoft.com
> >
> >