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

[Anil Yelundur <[e-mail]>]

Can multiple SAMs be sent? I thought only one SAM is allowed after the IAM...I am not
very sure.
Anil Yelundur

Jonathan Rosenberg wrote:

> 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