Subject: [SIP] INFO before 200

From: Christer Holmberg <[email-masked]>
Date: Wed, 07 Mar 2001 13:11:59 +0200

Hi,

I have changed a few words about the following issue with some people. I
also think the issue has been on the mailing list before, but I couldn't
find anything about it in the related drafts. It is also a little
related to the overlap dialing - not from a functional point of view,
but how it is done in SIP.

It is, again, related to PSTN/SIP interworking, and the issue is when
the UAC GW wants to send ISUP information before a final response has
been received. The example below shows one case where this could occur:

PSTN	UAC GW		UAS GW	  PSTN
--------------------------------------
   -IAM->    --INVITE-->     -IAM->

   <-INR-    <---18?----     <-INR-

   -INF->    ----???--->     -INF->

   <-CON-    <---200----     <-CON-

In this case, the first question is into which 18x message the ISUP INR
message should be mapped, but I guess that is a small issue.

The real issue, though, is how we transport the INF message in SIP. 

I KNOW it has been discussed about allowing SIP INFO messages before the
INVITE final response, but I am not sure this is been defined as a
sollution. After all, the INFO RFC says that the INFO method is allowed
only when a session has been setup. Also, proxies may not allow this, so
I think we need a solution that is more than "an agreement" between GW
vendors to allow INFO before the call is setup...

Another example where this is needed is if a ISUP FOT message is to be
sent, and there may also be other cases.

PSTN	UAC GW		UAS GW	  PSTN
--------------------------------------
   -IAM->    --INVITE-->     -IAM->

   -FOT->    ---FOT---->     -FOT->

Also, a re-INVITE could maybe be a solution here, but I am not sure if
that is the best solution. Also, it raises some issues that I mentioned
in another mail about ISUP message-bodies in session-timer re-INVITEs.

Comments?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Billy Biggs <[email-masked]>
Date: Wed, 7 Mar 2001 09:55:00 -0500

> been received. The example below shows one case where this could

  Allowing INFO before a connection doesn't make sense with forking.
Say you did send an INFO before the final 200 was received, you still
don't have a 2-way connection up yet.  You may not even be connected to
any endpoint, some proxy in the middle might send a ringing as it queues
you up for some reason.  More explicitly:

 PSTN	UAC GW		UAS GW	  PSTN

    -INF->    ----INFO-->     -INF->
              <---OK-----

                         [proxy forks to new endpoint]

  So, the first endpoint saw the INFO message, but the second
sequentially forked endpoint did not.  The calling UAC receives no
indication that this occurred.

  In my opinion, we need a new extension to better handle gateways using
SIP, and not just PSTN gateways.  To illustrate:

 PSTN	UAC GW		UAS GW	  PSTN
 
    <-INR-    <---200----     <-INR-    [uas gw immediately connects]
 
    -INF->    ----INFO-->     -INF->
              <---OK-----

    <-CON-    <-CALLINFO-     <-CON-
              ----OK---->

  We can define some new method (let's call it CALLINFO) which allows
the endpoint to convey gatewayed call status.  This could be a solution
to a whole bunch of issues relating to gateways:

  1. When a phone dynamically becomes a SIP gateway (say it performs
     transfer by bridging) it can use CINFO to tell the far end about
     the status of the bridged (gatewayed) call.

  2. We can now handle overlap dialing in a clean way.  Digits can be
     sent using either network tones RTP payload or INFO messages, and
     call status can be updated after the SIP connection setup.

  3. Early media isn't an issue, since we have setup a point-to-point
     connection and can send media happily.

  So, a call would look something like:

  -> INVITE sip:gateway
     Supported: gw-status

  <- CINFO sip:caller
     Content-Type: application/call-status

     180 Ringing

  -> INFO sip:gateway
     Content-Type: isup

  <- CINFO sip:caller
     Content-Type: application/call-status

     200 Connected

  The SIP call is connected, but the gatewayed call is not.

  Thoughts?

-- 
Billy Biggs                     [email-masked]
http://www.billybiggs.com/      [email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor'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" in the body.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 07 Mar 2001 17:06:20 +0200

Hi Billy,

> you up for some reason.  More explicitly:

I agree. This is related to the routing issues we also have in overlap
dialing. For the forking issue, it has been suggested that the UAS GW
would insert a Contact in the provisional response, and proxis may
insert Record-Route headers. Those would then be used to route the INFO
along the same route as the INVITE (ie. we would allow to use the Route
headers received in the provisional response). Of course, this would
assume that the UAS GW ALWAYS send a provisional response as soon as it
receives an INVITE, but that is also something we discussed for overlap
dialing.

>SIP, and not just PSTN gateways.  To illustrate:

There are some issues with this:
1. There has been discussions on when the 200 response should be sent,
and I think the general understanding is that it will not be sent before
the call is established.

2. We would have to send the 200 even if there is no INR received by the
UAS GW, becuase there may be a ISUP FOT message (see my previous mail)
to be sent by the UAC GW.

>  The SIP call is connected, but the gatewayed call is not.

We had a loooooooooooooong discussion about this earlier, when we
discussed the overlap dialing :) There were different opinions on when a
call is setup from a SIP point of view, and when the call is setup from
the user-to-user point of view...

>  Thoughts?

I agree that we could solve a number of things be having a gw-status.
But, how would intermedite proxies handle the CINFO?

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 7 Mar 2001 10:56:56 -0500

see embedded comments & questions below

----- Original Message -----
From: "Christer Holmberg" <[email-masked]>
To: "Billy Biggs" <[email-masked]>
Cc: "SIP List" <[email-masked]>
Sent: Wednesday, March 07, 2001 10:06 AM
Subject: Re: [SIP] INFO before 200

> receives an INVITE, but that is also something we discussed for overlap
Under what circumstances would a proxy fork a request after delivering it to
an INVITE to an endpoint? The INVITE would have to reach the SS7 Gateway in
order for an INR to be generated.  The INFO request is being generated
because the far end has requested the information in the provisional
response. The gateway should include the Contact header in the 18? response
so that the INFO request can be directed to that gateway even if a proxy
along the way had forked the INVITE.

Alternatively, could the INF be sent in a PRACK instead of and INFO?

> But, how would intermedite proxies handle the CINFO?
I don't think we really need a new method. This just seems like a different
flavor of the INFO method. I think it is clear that endpoints need to
exchange information in the process of setting up a session and there are
multiple states of setup where the end-to-end path has been established. The
UAC and UAS need to be able to use provisional responses and PRACK and/or
INFO requests to exchange this information.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 07 Mar 2001 18:14:15 +0200

Hi,

>along the way had forked the INVITE.

If the gateway includes a Contact in the provisional respones, and if
the gateway sends a provisonal response in the first place, there
shouldn't be a problem.

One issue is, however, if the INVITE is forked. Then we may get
provisional responses from more than one gateway. Where would we then
send the INFO (or whatever method is used) if the UAC GW wants to send
an ISUP FOR, or another ISUP message which doesn't need a "trigger" from
the destination network? Should we store all Contacts we get, and then
send the embedded FOR to all of them?

Of course, the operator can build and configure his network so that this
doesn't happend.
 
>Alternatively, could the INF be sent in a PRACK instead of and INFO?

I don't think that would be a good use of PRACK, because may not even
have a 18x response to PRACK. And, I don't think it's a good idea (it
would probably not even work...) to PRACK an old provisional response,
which we also may already have PRACKed...

>INFO requests to exchange this information.

A quick and not-so-nice solution could be to use re-INVITEs (compare to
overlap dialing), and have some extension header indicating that this
re-INVITE is only used to transport an ISUP message. Maybe an extra
header would maybe not even be needed, if the UAS GW is smart enough to
notice that the To header hasn't changed. This solution would probably
also work with existing proxies, assuming that they accept initial
INVITEs with Route headers. There are some issues with this, though:

1. What final response should we get to this re-INVITE? 200, even if the
call isn't setup?

2. This is just my personal opinion, but again we would have to send an
extra ACK simply to ack that an ISUP message was sent.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Billy Biggs <[email-masked]>
Date: Wed, 7 Mar 2001 13:06:24 -0500

Christer,

  Based on the discussions on early media, overlap dialing, and
ISUP-SIP-ISUP tunnelling, I see these general requirements for gateways:

  1. The caller needs to send additional information to the called party
     before the gatewayed call is established (digits?  random ISUP
     messages?  who knows what else).

  2. The called party needs to send required additional information to
     the caller before the gatewayed call is established (all the stuff
     you need PRACK for).

  3. Media must be allowed to flow before the gatewayed call is
     established (this is clear from implementations out there).

  Each of these requirements implies the establishment of a
point-to-point connection.  Otherwise, the called party may have
incomplete information (one INF message sent to one gateway, another INF
message to a separate gateway).

  I think that it is ridiculous to define extensions each of these
requirements.  I strongly believe that if a gateway wishes to handle an
incoming call, it should establish a point-to-point connection first and
then worry about call setup on the gatewayed side.  Then we can worry
about defining extensions to convey state about the gatewayed call, and
all of the ISUP proxying can be happily done using INFO.

  I'm scared about the alternative (which seems to be the current
direction).  It seems evident that the eventual requirements are:

  1.  All gateways MUST support sending and receiving PRACK.

  2.  All gateways MUST support extension X for sending INFO messages to
      some address received in some 18x response.

  3.  All phones calling a gateway MUST send SDP and be prepared to
      receive early media (difficult when you try to transfer a phone
      which is on hold!)

  4.  All proxies must be configured to never fork or cancel a call to a
      gateway.

  I just think it's too complicated.

> But, how would intermedite proxies handle the CINFO?

  If a SIP call is established, transactions can happily be sent along
the established call leg in both directions.

---

From: Jean-Francois Mule <[email-masked]>
Date: Wed, 7 Mar 2001 22:58:15 -0800

I guess I am unclear on what the isup INR msg is intended for besides
overlap dialing/sending?  without restarting the lenghty thread on
overlap dialing/sending, if some could give specific examples, it may
help...
Jean-Francois Mule.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Billy Biggs
> Sent: Wednesday, March 07, 2001 6:55 AM
> To: Christer Holmberg
> Cc: SIP List

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 08 Mar 2001 09:57:05 +0200

Hi,

You may use INR to request all kind of information. An example (shown in
the picture below), if your A-number is not provided in the IAM the
receiver can send an INR to request for it. This can happend, for
example, if you call the police/FBI/secret service/whatever...

PSTN       UAS GW              UAC GW     PSTN
----------------------------------------------

   --IAM-->        -INVITE->        --IAM-->       
(no A-number)  (From:unknown@...) (no A-number)

   <--INR--        <-18x?---        <--INR--

   --INF-->        --????-->        --INF-->

Now, in this specific case it would maybe make sense to send a new
INVITE, with a new From header, but we need a general solution that
works whatever information is requested. Also, like I mentined earlier,
this is needed also for other ISUP messages than INR/INF, so...

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 08 Mar 2001 11:13:37 +0200

Hi Billy,

>      messages?  who knows what else).

I agree.

>      the caller before the gatewayed call is established (all the stuff

I agree (even if I am not sure you really need PRACK for all that, but
that's another issue...).

>      established (this is clear from implementations out there).

I agree.

So, I do agree on all these requirements. The issue is how it will be
done.

>message to a separate gateway).

I am not sure that is the biggest problem, because it can be solved
using Route headers in provisional responses. During the overlap dialing
discussion we agreed (I hope) that a gateway should ALWAYS send some 18x
provisional response when the INVITE is received.
 
>requirements.

I agree, because then we would end up with a ISUP-on-IP protocol...

>I strongly believe that if a gateway wishes to handle an

If our gateway always talks to another gateway (ie we only use if for
ISUP trunking) I guess we could send a 200 when the SIP connection is
established, even if the PSTN side still needs information before the
end-to-end connection can be established.

The issue is that a gateway can also speak to a SIP phone. In this case,
the gateway still would have to send a 200 when the connection is
established, because it doesn't know if more information is needed to
establish the call. It may not even know if the sender is a gateway in
the first place... Of course, we can indicate in the INVITE if the UAC
is a gateway or a SIP phone, and the UAS will then behave different
depending on that.

This again shows something I have mentioned before. I think that a
gateway should be defined as a separate SIP node, not as a UA as it is
now. This would make it possible to define specific behaviour, and
possible a number of extensions, which have to be supported.

>   1.  All gateways MUST support sending and receiving PRACK.

I am not sure if that is a MUST, unless we will start sending ISUP
information in the PRACKs - which I hope we will not.
 
>       some address received in some 18x response.

It is still to be defined if any extensions are needed. 

It depends on how this whole issue will be solved. In general, however,
I don't see it as a huge problem that a gateway would have to support a
specific extension. It would simply be a MUST for a "Gateway SIP Node".
 
>       receive early media (difficult when you try to transfer a phone

I don't see this as a problem for the gateway. Instead I would use a
typical answer for this: If a phone can't handle it, don't buy that
phone... :)
 
>   4.  All proxies must be configured to never fork or cancel a call to a

This is a question of how the operator configure his network. If a call
is supposed to go to a specific gateway, and since that gateway most
often is located on a statical place, I see no need to fork the request
- at least not to do a parallell fork.
 
>the established call leg in both directions.

When I think about it, I'm not sure it's needed. I mean, if proxies will
accept the PRACK, which is also sent before the call leg is established,
they should also accept CINFO, INFO, or whatever method we will use.
Right?

Regards,

Christer Holmberg
Ericsson Finland

---

From: Billy Biggs <[email-masked]>
Date: Thu, 8 Mar 2001 17:22:06 -0500

Hi Christer, I'm glad we agree on the requirements.

> > point-to-point connection.  [...]
> 
> using Route headers in provisional responses. During the overlap
> dialing discussion we agreed (I hope) that a gateway should ALWAYS
> send some 18x provisional response when the INVITE is received.

  However, you are still connected to a multi-party tree.  Until you get
a 200-class response, you may be talking to 1 node or 5 nodes, or you
may suddenly switch from talking to one set of nodes to another.
Whatever the proxy network decides.  If you establish a Route by a
provisional response, you now have to deal with:

  a) worrying about whether that branch still exists (maybe it got
     CANCELed).
  b) handling multiple provisional responses each with a Route.  The
     caller can't cancel a branch, only the proxy which (sequentially?)
     forked can.  Does the new route replace the old one for new INFOs?
  c) the provisional response MUST be sent reliably (since we need it to
     send INFOs).

  All of this being more *required* complexity.

> The issue is that a gateway can also speak to a SIP phone. In this
> case, the gateway still would have to send a 200 when the connection
> is established, because it doesn't know if more information is needed
> to establish the call. It may not even know if the sender is a gateway
> in the first place... Of course, we can indicate in the INVITE if the
> UAC is a gateway or a SIP phone, and the UAS will then behave
> different depending on that.

  Why is it bad to send a 200 immediately to a SIP phone?  I think it
makes total sense.  Every gateway I have ever seen unconditionally sends
early media, so they're all assuming a single two-party connection
already.

  I believe that when you make a call to the PSTN, the 200 OK means an
establishment of a SIP connection (media flows etc).  Something else can
indicate establishment of the gatewayed call if necessary.

  I don't see the reasoning to model a gateway as a seperate node.  I
believe all of the reasons for immediately establishing a SIP call hold
equally for SIP phones.

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 8 Mar 2001 19:03:52 -0500

.
----- Original Message -----
From: "Billy Biggs" <[email-masked]>
To: "Christer Holmberg" <[email-masked]>
Cc: "SIP List" <[email-masked]>
Sent: Thursday, March 08, 2001 5:22 PM
Subject: Re: [SIP] INFO before 200

>      forked can.  Does the new route replace the old one for new INFOs?

I think the UAC needs to maintain state for each forked call-leg that has
reached a UAS on the other end (i.e. it has received a provisional response
with a Contact and possibly some Route headers) and send the INFOs to only
those UASs that need (or request) the info (e.g ISUP stuff like INFs, SAMs
and FORs).

Cannot a UAC CANCEL a particular branch if it knows the UAS that received
the INVITE? I would think it could get enough information from the
provisional response in the Contact, Route and To (w/tag) headers to send
the CANCEL to the specific UAS just as it would send the INFO to the
specific UAS. Although I suppose this would require the forking proxy to
notice that a branch it made is being cancelled.

> early media, so they're all assuming a single two-party connection
The problem with sending a 200 OK immediately is that for a call it implies
that the call has been answered. I believe that many implementations which
do any sort of billing will start charging at this point even though the
called phone is only ringing. Then you need some other event from the UAS
back to the UAC to indicate an Answer.

It is also the end of the INVITE transaction, and any trasaction stateful
SIP proxies might discard the state necessary for processing/routing
subsequent INFO requests related to call setup.

Also, the 200 OK requires the forking proxy to CANCEL all other branches and
I'm not sure you want to require the call to go to whichever gateway
happened to to get the INVITE first.

I personally like the idea of being able to send INFOs once an INVITE has
reached a UAS and a 18x has come back. However, this might violate RFC
2976's rule that INFOs MUST NOT change call state.

---

From: Billy Biggs <[email-masked]>
Date: Thu, 8 Mar 2001 20:03:16 -0500

Bob Penfield ([email-masked]):

> I think the UAC needs to maintain state for each forked call-leg that
> has reached a UAS on the other end (i.e. it has received a provisional
> response with a Contact and possibly some Route headers) and send the
> INFOs to only those UASs that need (or request) the info (e.g ISUP
> stuff like INFs, SAMs and FORs).

  This is one mess I would like to avoid.

> Cannot a UAC CANCEL a particular branch if it knows the UAS that
> received the INVITE?

  No.  CANCEL is handled hop-by-hop.  The calling UAC cannot cancel
specific branches of an upstream proxy.

> The problem with sending a 200 OK immediately is that for a call it
> implies that the call has been answered. I believe that many
> implementations which do any sort of billing will start charging at
> this point even though the called phone is only ringing. Then you need
> some other event from the UAS back to the UAC to indicate an Answer.

  I believe that using another event to indicate start-of-billing is a
much cleaner solution (maybe send the signalling message in an INFO).

> It is also the end of the INVITE transaction, and any trasaction
> stateful SIP proxies might discard the state necessary for
> processing/routing subsequent INFO requests related to call setup.

  This is not an issue.  INFO requests are routed like any other
mid-call transaction.  Proxies can record-route if they need to, but any
proxy application which needs to look inside INFO requests should
probably not be a proxy.

> Also, the 200 OK requires the forking proxy to CANCEL all other
> branches and I'm not sure you want to require the call to go to
> whichever gateway happened to to get the INVITE first.

  No, you want the proxy to load balance between which gateway will
handle the call.  Proxies can definitely be given enough information to
do this.

  People on this list keep saying that in properly implemented networks,
any call which terminates at a PSTN gateway should never fork (early
media concerns).  If that's the case, then why not be more honest about
it and connect the call, especially if it simplifies gatewaying ISUP
over SIP, overlap dialing, and I suspect completely removes the need for
PRACK.

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 9 Mar 2001 09:01:52 -0500

see embedded comments below
----- Original Message -----
From: "Billy Biggs" <[email-masked]>
To: "Bob Penfield" <[email-masked]>
Cc: "Christer Holmberg" <[email-masked]>; "SIP List"
<[email-masked]>
Sent: Thursday, March 08, 2001 8:03 PM
Subject: Re: [SIP] INFO before 200

>   This is one mess I would like to avoid.

I agree that this is a mess. I suppose the UAC would only need to remember
the UASs if it were using INFOs to send unsolicited data. In the INR/INF
example, the UAC simply sends the INFO with the INF to the UAS that sent the
INR in its 18x response.

> much cleaner solution (maybe send the signalling message in an INFO).
I agree that it would be cleaner, but aren't we too far down the SIP road to
make a change like this?

> handle the call.  Proxies can definitely be given enough information to
I was thinking of an application where a given user might be reachable at
multiple end-points (e.g. home. office, cell) and a proxy forked the INVITE
to all of those endpoints. If more than one of them were reachable via SS7
gateways you could have multiple gateways sending an immediate response. In
this case, the proxy needs to wait for one of those calls to be answered
before cancelling the others.

> over SIP, overlap dialing, and I suspect completely removes the need for
Applications like multiple endpoints for one user will require prxoies to
fork.

---

From: Billy Biggs <[email-masked]>
Date: Fri, 9 Mar 2001 10:04:46 -0500

Bob Penfield ([email-masked]):

> I agree that this is a mess. I suppose the UAC would only need to
> remember the UASs if it were using INFOs to send unsolicited data. In
> the INR/INF example, the UAC simply sends the INFO with the INF to the
> UAS that sent the INR in its 18x response.

  ... which may be multiple endpoints if multiple 18x responses are
received, and if the proxy forks in the middle of the call, the new
gateway will not have seen the old INFO messages which may have
contained call-critical information.

> >   I believe that using another event to indicate start-of-billing is
> > a much cleaner solution (maybe send the signalling message in an
> > INFO).
>
> I agree that it would be cleaner, but aren't we too far down the SIP
> road to make a change like this?

  It would be an operational change, not a protocol change.

> > > [...] I'm not sure you want to require the call to go to whichever
> > > gateway happened to to get the INVITE first.
> >
> I was thinking of an application where a given user might be reachable
> at multiple end-points (e.g. home. office, cell) and a proxy forked
> the INVITE to all of those endpoints. If more than one of them were
> reachable via SS7 gateways you could have multiple gateways sending an
> immediate response. In this case, the proxy needs to wait for one of
> those calls to be answered before cancelling the others.

  Forking works great if all of the nodes you are forking to are SIP
phones.  It does not work so well when you have PSTN gateways, unless
you know the specific properties of the number you are calling.  I
invite you to experiment with any of the SIP-PSTN gateways available
today and see the problems.

  1. Parallel forking to multiple PSTN numbers:
     Each gateway will send early media unconditionally.  You can bet
     this doesn't sound very good to the caller.

  2. Sequential forking to multiple PSTN numbers:
     Many error conditions seem to be sent only in the early audio path,
     and as such cannot be detected by gateways.  For example, "the
     number you have reached is not in service" announcements or busy
     signals.  This makes rules likes "try my cell, but if it's busy or
     unavailable, fork to my office phone".

  Unless you know for sure that when you fork to your cellphone and it's
not available, then the gateway will return some appropriate SIP error
response, then sequential forking rules are useless.

  Maybe a better idea would be to have a header which can be added by
proxies who know that the number they are dialing exhibits these
properties?  Then, calls in controlled environments can fork correctly,
but all other calls will be connected immediately.  This would solve all
the nasty 1-800 call problems without harming some known-working forking
rules.

  Thoughts?