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

[Chip Sharp <[e-mail]>]

At 04:44 PM 11/19/99 +0200, Gonzalo Camarillo wrote:
>Hi,
>
>We are talking about several problems, all related to overlap
>signalling.
>
>First of all, this is what draft-camarillo-mmusic-sip-isup-bcp-00.txt
>says in the chapter 7.1 about this. This is the chapter that has to
>contain the solution that is found to be the best.
...snip...
>The problem of a user typing # :
>In the States 'en-bloc' signalling is used, so this is not needed. In
>Europe, the use of 'en-bloc' signalling is becoming more and more common
>due to the use of mobiles (in Finland there are more mobiles than fixed
>phones).

FWIW,
When dialing international calls from the US, the user usually must either 
enter "#" or wait for a timeout for the call to be completed.  In most 
countries I have travelled in, I have found that entering "#" to terminate 
"dialing" at least does no harm.  Sometimes it speeds up post dial delay by 
a couple of seconds.

>Therefore, the problem i getting smaller and smaller. However, we have
>to provide backwards compatibility.
>We are here for finding a solution to the problem. If we do not find a
>solution, we can tell all the users to press # after the phone number,
>but I wouldn't say that this is "finding a solution" :o)
>
>Problem of imcomplete To field:
>If the i-gateway sends (as Jonathan suggests) an INVITE with some
>digits, and then adds the rest of them to the request URI, the To filed
>is not going to be complete. It will contain just some digits.
>Are we OK with this?
>We may have:
>
>INVITE 123456@...
>To: 123@...
>
>Because we received 123 in the IAM, and 456 in SAMs (a single SAM can
>contain several digits).
>
>This means that the information contained in the SIP fields is not
>really correct. And we are talking about mandatory fields. That's why I
>was trying to avoid this. If nobody sees a problem with this we can
>proceed this way.
>
>By the way, the trade-off I pointed out in the draft is still there. If
>we issue an INVITE every time we get a SAM, we will generate lots of
>messages. I still think that the timer I was proposing is an idea to
>take into account.
>
>Any comments?
>
>Gonzalo
>
>[e-mail] 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
>
>--
>Gonzalo Camarillo         Phone :  [phone]
>Oy L M Ericsson Ab        Mobile:  [phone]
>Telecom R&D               Fax   :  [phone]
>FIN-02420 Jorvas          Email :  [e-mail]
>Finland

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------