Subject: Re: [SIP] Operlap dialing within a SIP network

From: "Keith Robinson" <[email-masked]>
Date: Mon, 5 Feb 2001 13:33:50 +0000

In your text  do you mean 484 and not 486 ?

If it is legal for a gateway interworking with the PSTN to gather
digits using the INFO message and responding with some 18X response
then I don't see why it can't be legal for the server you have defined in this
scenario.

Such a server now has two choices for collecting digits; it either issues a 18X
and
waits for further digits in the INFO message, or it issues 484 and waits for the
subsequent INVITE.

The choice will probably be dictated by the implementationof the digit decode.
If the implementation for
decoding digits is more efficiently used by starting it off and then passing it
subsequent digits, the 484 method would be inefficient as this would mean
clearing
down the algorithm state between INVITEs and starting it off again on the
subsequent
initial INVITE (as otherwise there is a problem with the subsequent initial
INVITEs
getting to the same server as I have previously highlighted); if the
implemtation is equally
efficient whether it decodes anew each time or on a digit string  by digit
string basis, then the 484
method would be the best.

Regards,

K. Robinson.

Christer Holmberg <[email-masked]> on 05/02/2001 12:14:21

                                                              

 To:      [email-masked]                             
                                                              
 cc:      (bcc: Keith Robinson/MAIN/MC1)                      

 Subject: Re: [SIP] Operlap dialing within a SIP network      

I would like to clarify the scenario a little.

The SIP server is NOT a normal proxy in the SIP network, via which the
INVITE is routed to the UAS (if it was, we would use 486 responses until
the proxy can route the call to the UAS, like Tom proposed earlier in
the Operlap Dialing thread).

Instead, the server could be some kind of automatic phone switch, for
example connected to a VPN. The difference from a NAT would be that it
is connected directly to a number of UAS, so it needs the digits to be
able to find the correct UAS.

If the UAS would be, for example, a PSTN phone, the SIP server would be
a PSTN GW, so then it would be allowed, but what is it wants to use the
same logic to route a call to another network using SIP (or, maybe
another VoIP protocol).

Regards,

Christer Holmberg
Ericsson Finland

> Hi,
>
> The discussion about overlap dialing has been pretty much about calls
> from SIP to PSTN, or PSTN-SIP-PSTN.
>
> Consider the following scenario.
>
> PSTN PHONE             GW           SIP SERVER      SIP UAS
> -----------------------------------------------------------
>
> --- 1 --->    -- IAM -> | -- INVITE -->  |
>                         | <- 18x ------  |
> --- 2 --->    -- SAM -> | -- INFO ---->  |
>                         | <- 200 (INFO)  |
>                         | <- 18x ------  |
> --- 3 --->    -- SAM -> | -- INFO ---->  |
>                         | <- 200 (INFO)  |   -- INVITE
> -->
>                         | <- 200 (INVITE)|   <- 200 ------
>
> In this case, the SIP server (note that I am not using the word 'proxy')
> must collect digits, sent from the PSTN side using overlap dialing, to
> be able to find the SIP UAS, and INFO is used to provide the digits
> after the INVITE has been sent.
>
> My question is, should a SIP server (proxy, if you like) be allowed to
> behave like this, or MUST it send 486s, and receive new INVITEs, until
> it is able to find the UAS?
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 05 Feb 2001 15:43:09 +0200

I meant 484. Sorry. :)

Christer Holmberg
Ericsson Finland