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

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 6 Feb 2001 17:44:04 -0500

Just to re-hash, in the ISUP-SIP-ISUP context, once call signalling has
reached an egress gateway, SIP has done its job -- additional digits will
not change call state.  It is therefore reasonable to use INFO to carry the
additional digits.  If we are talking ISUP-SIP, once the destination UAS or
a UAS in a B2BUA has been reached, the same consideration applies.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2001 1:15 AM
> To: Gonzalo Camarillo
> Cc: [email-masked]
> Subject: Re: [SIP] Operlap dialing within a SIP network
> 
> 
> 
> Hi Gonzalo,
> 
> I didn't say I am going to use INFO, but that is what has 
> been proposed
> earlier in this thread, so I assumed INFO would be used. The 
> reason for
> the discussion from the beginning was that the overlap signalling,
> according to the SIP-ISUP mapping draft, may not work very well, and a
> solution using 18x responses and INFO messages, instead of 484 and
> re-INVITEs, was proposed.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> Gonzalo Camarillo wrote:
> > 
> > Hello Christer,
> > 
> > Why are you using INFO for sending extra digits?
> > 
> > Please, check the SIP-ISUP mapping draft, overlap 
> signalling section.
> > 
> > Regards,
> > 
> > Gonzalo
> > 
> > Christer Holmberg wrote:
> > >
> > > 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
> > 
> > --
> > Gonzalo Camarillo         Phone :  +358  9 299 33 71
> > Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> > Telecom R&D               Fax   :  +358  9 299 30 52
> > FIN-02420 Jorvas          Email :  [email-masked]
> > Finland                   http://www.hut.fi/~gonzalo
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 07 Feb 2001 04:09:57 +0200

Hello Tom,

Tom-PT Taylor wrote:
> 
> Just to re-hash, in the ISUP-SIP-ISUP context, once call signalling
> has reached an egress gateway, SIP has done its job -- additional
> digits will not change call state.  It is therefore reasonable to use
> INFO to carry the additional digits.  If we are talking ISUP-SIP, once
> the destination UAS or a UAS in a B2BUA has been reached, the same
> consideration applies.
> 

I do not agree with these two statements:

The 1st INVITE (with just some digits) arrives to a vanilla SIP UA. I
will return a Not Found or a 484 Address incomplete. The subsequent INFO
carrying more digits will be discarded. Thus, the PSTN to SIP gateway
will have to re issue a new INVITE with all the digits. Therefore, it is
better to begin directly using er-INVITEs rather than INFO.

Besides, I do not think that SIP is just a transport protocol that
carries ISUP messages between two gateways. For that, we have already
SIGTRAN. SIP might be used to provide services, even when the call is a
PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete state. And a
SIP message with an incomplete to field does not carry complete state.
What if my SIP proxy provides a service for a PSTN-SIP-PSTN call based
on the to field (called party number). That proxy would like to see an
updated to field, not just a to field that contains just some digits.

Best regards,

Gonzalo

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