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

[Gonzalo Camarillo <[e-mail]>]

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.

********
7.1 Address received

   Upon the reception of an IAM resources are reserved in the MG and it
   gets backward through connected.

   The B-party number can be received in just one IAM ('en bloc'
   signalling) or in one IAM followed by one or several SAMs (overlap
   signalling). In some countries there is no way for the MGC to know
   whether the B-party number is already complete or some SAMs will
   still arrive.

   If the MGC relies on the inter-digit timeout to assume that the
   number is complete the establishment of the connection is delayed.
   Alternatively, if the MGC sends the INVITE request immediately after
   receiving the IAM heavy signalling traffic may be generated.

   Therefore every individual MGC must be configured with a specific
   timer. If an MGC never receives a SAM the value of the timer should
   be zero. If the reception of a SAM is likely the value of the timer
   should be sufficient for receiving them before the INVITE is sent
   (after receiving the minimum amount of digits that can represent a
   number, around 5 seconds).

   Thus, after receiving the B-party number, the MGC issues an INVITE
   request. If after sending this request a SAM is received the MGC
   will CANCEL the INVITE and send a new INVITE to the complete
   address. If a '484 Address Incomplete' is received the MGC should
   wait for subsequent SAMs and send a new INVITE.
**************

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).
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