Subject: 484 Rerouting (Was: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt)

From: "Pete Cordell" <[email-masked]>
Date: Fri, 26 Nov 1999 12:57:40 -0000

One embellishment that may make the 484 process more efficient might be to
include an address of where subsequent INVITEs are to be sent.  This will
allow proxies that have already done their forwarding to not be involved in
subsequent lookups.  A call flow might look like:

UAC to proxy A:
    INVITE +4

Proxy A to UAC:
    484

UAC to Proxy A:
    INVITE +49

Proxy A to Proxy B:
    INVITE +49

Proxy B to Proxy A:
    484 next-lookup: Proxy B

Proxy A to UAC:
    484 next-lookup: Proxy B

UAC to Proxy B:
    INVITE +492

etc.

This does make the process more complicated, but would reduce the burden on
lookup proxies.  I think it can be an optional thing to implement as I think
it still works if a dumb proxy copies the whole 484 response to the
originator.  Elements that want to stay in the signalling path would have to
do some tweaking.

If the proxies could also specify the minimum number of digits they require
each proxy only gets about 2 hits per call, which doesn't seem too bad.
e.g.:

UAC to proxy A:
    INVITE +4

Proxy A to UAC:
    484 min-digits: 2

UAC to Proxy A:
    INVITE +49

Proxy A to Proxy B:
    INVITE +49

Proxy B to Proxy A:
    484 min-digits: 5 next-lookup: Proxy B

Proxy A to UAC:
    484 min-digits: 5 next-lookup: Proxy B

UAC to Proxy B:
    INVITE +49255

Proxy B to Proxy C:
    INVITE: +49255

Proxy C to Proxy B:
    484 min-digits: 10 next-lookup: Proxy C

Proxy B to UAC:
    484 min-digits: 10 next-lookup: Proxy C

UAC to Proxy C:
    INVITE +4925532145

You get the idea....

Pete

-----Original Message-----
From: Henning Schulzrinne <[email-masked]>

>Matt Cannon wrote:
>>
>
>> The thought of a large number of INVITES and 484
>> response messages flying across the network to make
>> overlap work just makes me shake my head.
>
>To get some feeling as to how bad (or not) this might be, I wonder if
>there's any sense as to the per-country variation in number length. It
>is probably reasonable for a gateway to know the minimum digit string
>length for each country, so only digits beyond that would need to be
>signaled digit-by-digit. (It is also very unlikely that the minimum will
>suddenly drop, so updates should not be an issue.) Any observations?
>
>(By the way, the 484 overlap signaling method is already in the SIP
>spec, as this topic has been around a few times...)
>
>I agree that we should avoid this as much as possible.
>--
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
>

=============================================
Pete Cordell
[email-masked]
=============================================