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

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 6 Feb 2001 21:19:23 -0500

Sorry, we're talking past each other.  The premise of my statements is that
an INVITE has reached a UAS which has accepted it.  It follows that the UAS
did not send back a 484, but rather an interim response.  IF more digits
come along, the INFO method is there to carry them.  They do not affect the
SIP call state; they are used beyond the UAS, either in a PSTN call or in
another SIP call as the case may be.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2001 9:10 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Christer Holmberg; [email-masked]
> Subject: Re: [SIP] Operlap dialing within a SIP network
> 
> 
> 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
> 
> 
> > > -----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
> > >
> 
> -- 
> 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:52:18 +0200

Hi Tom,

Still I want to have full state in every SIP message. If the call is
addresed to the phone number 1234, I want to have a to field that says
1234. I do not care if there is a leg routed thru the PSTN and another
thru SIP.

Carrying full state is one of the beauties of SIP. If we begin using
INFO for this, it would be the same as using SAMs. Differen names, the
same thing... I do not want to re-create ISUP using SIP. I believe that
if the session has a destination, it should be present in the to field.

Again, if a proxy is providing services for this particular call, it
will want to see the called party number in order to trigger the proper
service. This is a very good reason for updating the to field every time
we have more digits.

I like to use SIP between two gateways because it is possible to provide
SIP services for a PSTN to PSTN call. If all we want to do is finding a
egrees gateway, we would probably want to use other protocols (TRIP &
SIGTRAN for instance).

Regards,

Gonzalo

Tom-PT Taylor wrote:
> 
> Sorry, we're talking past each other.  The premise of my statements is
> that an INVITE has reached a UAS which has accepted it.  It follows
> that the UAS did not send back a 484, but rather an interim response.
> IF more digits come along, the INFO method is there to carry them.
> They do not affect the SIP call state; they are used beyond the UAS,
> either in a PSTN call or in another SIP call as the case may be.
> 
> > > > From: Christer Holmberg
> [mailto:[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.