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

From: "Mark Watson" <[email-masked]>
Date: Tue, 13 Feb 2001 13:59:51 -0000

Gonzalo,

I'm not sure were completely understanding each other here.

I think we do agree that there is value in the SIP-T concept, so that the
PSTN can interwork with services provided in the 'pure SIP' network by SIP
proxy servers.

I think that the path we're on of including ISUP messages inside SIP
messages is as good as any other for this, so I don't see any value in
pursuing alternatives, such as setting up a SIGTRAN session for the ISUP
signalling.

I do not see the problem, though, with allowing PSTN gateways to switch to a
more efficient mode of overlap signalling once the gateway out of the SIP
network has been identified. Sure, whilst the call is still progressing
through the SIP network, and we want to make use of the routing capabilities
in the SIP network, we use normal SIP procedures, but once we have hit the
PSTN gateway, why not optimise things ?

<snip>

> > 2) The UAC must use source routing to ensure that all these INVITES
> > make it to the same UAS
> 
> What is the problem here? This is done in order to address the problem
> of proxies performing load balancing. Some folks have pointed out that
> maybe the betwork wants to route the second INVITE in a 
> different way...
> why the network would like to do that? The policy that is 
> applicable to
> the fist INVITE (that contained a prefix of the number) should be the
> same that applies to the subsequent ones.

Why ? How can you possibly know that all services in all networks will work
this way ? There are a host of reasons why routing of the INVITE might vary
due to factors other than the digits. INVITES for the *same digits* might
route differently, and not just due to load balancing.

<snip>

> > The price we pay for this is that intermediate proxies may not have
> > access to the full Called Party Number - but a proxy that 
> needs this,
> > that wants to offer service on overlap calls, can always sniff the
> > overlap digits as they go past.
> 
> Let me get this straight. Are you are proposing to change the logic in
> all the already existing proxies because you want to provide services
> when you use INFO for carrying SAMs? This is just impossible.
> 

All proxies which want to provide services: 
a) which operate *after* the INVITE has been routed and the terminating
point in the SIP network found,
b) which require access to the full PSTN number,
c) on PSTN -> SIP-T -> PSTN calls,
d) which are delivered on overlap calls, and
e) which do not know the dial-plan well enough to identity end-of-dialling
themselves.

I think right now this is the empty set, so, yes, I can upgrade all these
:-)

Regards,

Mark Watson
Nortel Networks

> I still prefer a mechanism that do not require changes in the existing
> proxies (multiple call-legs).
> 
> Best regards,
> 
> Gonzalo
> 
> > 
> > Regards,
> > 
> > Mark Watson
> > Nortel Networks
> > 
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:[email-masked]]
> > > Sent: 07 February 2001 02:52
> > > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > Cc: Christer Holmberg; [email-masked]
> > > Subject: Re: [SIP] Operlap dialing within a SIP network
> > >
> > >
> > > 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.
> > > >
> > > > > -----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
> > > > >
> > >
> > > --
> > > 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
> > >
> > > _______________________________________________
> > > 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.
> > >
> 
> -- 
> 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: Christer Holmberg <[email-masked]>
Date: Tue, 13 Feb 2001 19:24:58 +0200

Hi,

I think it is important to define what we want to optimize - the SIP
network, the GW, or something else. I think that we during this
discussion has clarified that it will not matter very much on the PSTN
side, but on the SIP side. The advantages of using INFO - or, let say of
not using re-INVITEs - would be:

1. We save network capacity, because we don't have to send ACKs for
every re-INVITE. This may not sound too much for a single client but for
PSTN gateways, where overlap dialing most likely will be used, I think
we can assume that we are talking about a significant number of
messages.

2. The logic in the UAS GW would be more simple, because it would not
need
to compare the Request-URI in the re-INVITEs with the Request-URI in the
previous INVITE, to generate the correct SAM messages (using INFO, you
just send the new digits, and the GW generate SAMs of them).

3. If (again, this has nothing to do with the overlap procedure itself)
you have SDP body, and an encapsulated ISUP body (or any other
message-body), in the INVITE, you must send it in every re-INVITE also
(if you receive 484 you would probably always do so, but you may also
send your re-INVITE before you get a response, and/or a proxy may
suddenly re-route the INVITE to another GW, which needs the ISUP body).

The advantage of using re-INVITEs, however, are:

1. You can easier access services in the SIP network

2. The GW UAC have to wait for a non-484 response for your INVITEs
before you start using INFO, instead you can send your re-INVITEs as
soon as you receive a SAM from ISUP. It has been discussed that the GW
UAS would send some kind of provisional response when it has received
enough digits to route the call forward. So, until you get that
provisional response you will have to wait for the response to every
INVITE you send before you can send the next INVITE, which may include
buffering of SAMs in your GW UAC, and that is NOT to optimize. 

3. If TRANSACTION overlaping for INFO is not allowed you would also have
to wait for the response to every INFO you send before you can send the
next one, since they belong to the same call-leg (the re-INVITEs are all
different legs, so you don't have transaction overlaping there).

4. You can re-route the call setup to another MGC at any time (the
disadvantage is, like I mentioned, that you have to include your message
bodies, ISUP etc, in every INVITE), since every INVITE will have all
digits in the Request-URI. The new GW UAS would then simply handle the
INVITE as an initial INVITE. Yes, the proxy re-routing the call would
probably also have to CANCEL to old leg (if a 484 was not received,
which would happend if the GW managed to route the call forward in the
PSTN network). With INFO that would not be possible. First, the proxy
would have to "transfer" the INFO into an INVITE, but that would not
help because the UAC still has an ongoing INVITE transaction, and does
not want a response to an INFO method it never even sent.

Regards,

Christer Holmberg
Ericsson Finland

Mark Watson wrote:
> I think we do agree that there is value in the SIP-T concept, so that
> the PSTN can interwork with services provided in the 'pure SIP'
> network by SIP proxy servers.
> 
> pursuing alternatives, such as setting up a SIGTRAN session for the
> ISUP signalling.
> 
> I do not see the problem, though, with allowing PSTN gateways to
> switch to a more efficient mode of overlap signalling once the gateway
> out of the SIP network has been identified. Sure, whilst the call is
> still progressing through the SIP network, and we want to make use of
> the routing capabilities in the SIP network, we use normal SIP
> procedures, but once we have hit the PSTN gateway, why not optimise
> things ?
> 
> <snip>
> 
> Why ? How can you possibly know that all services in all networks will
> work this way ? There are a host of reasons why routing of the INVITE
> might vary due to factors other than the digits. INVITES for the *same
> digits* might route differently, and not just due to load balancing.
> 
> <snip>
> 
> a) which operate *after* the INVITE has been routed and the
> terminating point in the SIP network found,
> e) which do not know the dial-plan well enough to identity
> end-of-dialling themselves.
> 
> I think right now this is the empty set, so, yes, I can upgrade all
> these :-)
> 
> Regards,
> 
> Mark Watson
> Nortel Networks
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Feb 2001 00:11:05 +0200

Hello Mark,

> procedures, but once we have hit the PSTN gateway, why not optimise

Optimizing things means to use an optimal way for transporting overlap
signalling, right? Then, you want to use SIGTRAN. Efficient, allows
multi-homing, low overhead, etc...

Using INFO breaks all the application servers in the SIP network.
Besides, it breaks SIP itself (as I have been pointing out a number of
times in this thread already).

But people are more worried about saving one message (the ACK) than
about being coherent with the way SIP services will be provided.

> digits* might route differently, and not just due to load balancing.

Let me explain this point. If the network has routed in a certain way
(that, as you say, might depend on a thousand of parameters) the first
INVITE, the following INFOs (assuming that you use INFO for sending
SAMs) will be routed in the same way, right?

Well, then, the re-INVITEs belonging to the same call have to be routed
in the same way also. So, even if the network decides not to honor the
record route present in the INVITE, the message will be routed in the
same way.

The only expection is when the routing decision is made randomly, that
is, without depending on any parameters. This is, the same message might
be routed in a different way depending on the time of the day, for
instance. Then, this is load balancing, and that is why source routing
is used.

> I think right now this is the empty set, so, yes, I can upgrade all

All these proxies are NOT standard SIP proxies. They examine INFO
messages in order to provide services... if you want to implement your
network in a non-standard way, it is up to you. I will implement my
network in a way that allows the same SIP proxy to handle SIP-SIP calls,
PSTN-SIP calls, etc...

And this was Jonathan was trying to say in his mail. The application
server architecture will work well if re-INVITEs are used. It won't if
INFOs are used.

But anyway, if you still want to use INFO and you intend to implement
non-standard SIP proxies to provide your services, it is all up to
you... I just don't buy that.

Best 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]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 14 Feb 2001 00:20:12 +0200

Hello Christer,

This thread has already too many messages, and folks seem to respond

> just send the new digits, and the GW generate SAMs of them).

AS I said before, INFO does not ensure ordered delibery. So, if you do
what you are just describing, it will NOT work. You will get an INFO
with a SAM before the previous INFO with the previous SAM arrives... you
will just shuffle the digits of the number... BAD IDEA.

However, you might argue that you will use a new request-URI. Well, this
is not standard SIP again. You should honor the contact header you have
received, and not modify it on your own... again, you are thinking just
about gateways.

I would like you to think about normal clients, APS, etc... then, you
will see that instead of simplifying your gateways, you are adding
complexity, because you will have to implement standard SIP to interwork
with vanilla UAs and your SIP-T with INFOs to interwork with other
gateways.

Best regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Feb 2001 08:41:10 +0200

Gonzalo,

My mail was not yet another proposal for using INFO, I simply tried to
define how we could "optimize" our system by using re-INVITEs and by not
using re-INVITEs.
 
>>need to compare the Request-URI in the re-INVITEs with the Request-URI >>in the previous INVITE, to generate the correct SAM messages (using >>INFO, you just send the new digits, and the GW generate SAMs of them).
> 

Well, sending re-INVITEs doesn't ensure you more ordered delivery
either. Yes, the difference is that in the INVITE you will always
receive ALL digits, not only the new-ones, so that solves that issue.
 
>is not standard SIP again.

You could have a separate header in the INFO with ALL digits, but then
the digit processing in the UAS GW probably would not be more simple
than by using re-INVITEs, so I agree that you will not optimize in that
sense by using INFO :)

>You should honor the contact header you have received, and not modify it >on your own... again, you are thinking just about gateways.

What Contact header would I get in the 484 anyway??? The responding
gateway doesn't know which the new digits are going to be. I can only
get the host part in the Contact, and that is going to be the same no
matter which method I use.

E.g., assume I send an INVITE to [email-masked], and receive a 484. The UAC
gateway has now received more digits, 456, so I send a new INVITE to
[email-masked]. The UAS gateway, however, didn't know that I was going
to use that Request-URI, so it couldn't have put those extra digits in
the user part of the Contact header in the 484 response.

And, if I send the re-INVITE before I get the response to the previous
INVITE, OR I don't get a response at all because the UAS gateway has
received enough digits to route the call to the next PSTN entity, the
UAC gateway will not even get a Contact header before it sends the next
re-INVITE.

AND, according to the draft the Contact header in a 484 response is used
ONLY to indicate where more info about the error can be found, not where
to send the next request...

Regards,

Christer Holmberg
Ericsson Finland