Subject: [SIP] Overlap dialing Part II: We reached the UAS

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Feb 2001 00:49:06 +0200

Hi,

I started a separate thread on this, since I assume two things:

1. We only use INVITEs for the overlap dialing

2. The INVITE has reached the UAS, in this case a PSTN gateway.

Ok, as long as the gateway UAS doesn't have enough digits to forward the
call to the next entity it will send 484 responses. No problem there.

But, when it does find the next PSTN entity, the following issues come
up:

1. The gateway can not send a final response to the INVITE, since it
doesn't know what it is, IF is is, going to receive from ISUP. The
proxies on the path, and the UAC, will probably receive a 100
provisional responses, that will extend the re-transmission timer.
However, these re-transmissions are not necessary, and they MAY even end
up in another gateway, when we come back to the routing issue, and the
issue of multiple IAMs.

So, I would again like to raise the 186 issue. Ie, the UAS gateway could
send a "186 Call Routed Forward" provisional response which, IF the
proxies and the UAC supports it, would stop the re-transmission. Yes,
there may have been a re-transmission before the 186 is received, but at
least the chance of the problems above to occur is smaller. If the UAC
also is a gateway, this provisional response would not trigger any ISUP
message, it would simply be used for the SIP part of the gateway to stop
the re-transmission.

2. The call is routed to the end PSTN user, and the gateway receives a
an ISUP indication for that. Now, it generates a 200 OK for the previous
INVITE. BUT, what final response does it send to all the other existing
INVITE transactions, which arrived earlier, and did NOT trigger a 484
response since the gateway managed to route them to the next PSTN
entity? I don't think 200 OK is a good idea, because it may mess things
up at the UAC gateway (which has to map the "correct" 200 OK into an
ISUP message), and it is also against the statement that 200 OK
indicates that the call has been succesfully routed. Yes, in this case
it HAS been, but only for one call-leg, ie for the latest INVITE. The
closest I can think of is 484, but I don't know that is a good idea
either. 

For example, what happens if one of the 484 reaches the UAC gateway
before the 200 OK? The UAC gateway will realise it doesn't have more
digits, so it will release the call - unless, of course, it is smart
enough to know that it has sent a newer INVITE, with more digits. Again,
like with the 186 provisional response, some kind of final response
which will not be mapped into ISUP, or affect the call in any other way,
would be good? A final response only to "get rid" of the INVITE
transactions we don't care about anymore. 

In Dallas, a 202 response was proposed for another case, and maybe that
could be here too? A response that simply says: "Ok, your INVITE was
fine, but we don't need it anymore. So, please terminate it but don't
make a big noise about it".

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 16 Feb 2001 01:40:28 +0200

Hi,

186 is not needed because we have already 183 means session progress.

Since the gateway knows that the last INVITE was successful, it can
safely answer 484 to all the previous transactions. No new response code
needed.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.