Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

From: "Pete Cordell" <[email-masked]>
Date: Mon, 22 Nov 1999 12:40:22 -0000

Related to this thread is the case where we have a PSTN-SIP-PSTN call, and
we get the case where we have gone through Jonathan's scheme to get routing
all the way through the SIP part of the connection, but maybe this has only
got us to the Rhineland (in Henning's example) and the network decides to
jump back to PSTN.

In this case the egress PSTN side still needs to do overlap sending on the
legacy PSTN side.  I think we then need to use the INFO method of sending
dialling information.  This shouldn't be a problem though as we can simply
resort to this scheme once we have got a non-484 result (actually we need a
response something like ???? - uhm I'm not sure!!!)

Pete

=============================================
Pete Cordell
[email-masked]
=============================================

-----Original Message-----
From: Jonathan Rosenberg <[email-masked]>
To: Gonzalo Camarillo <[email-masked]>
Cc: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>;
[email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Date: 19 November 1999 16:21
Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt

>
>
>Gonzalo Camarillo wrote:
>>
>> > 4. This works *even* if there is misordering of re-INVITEs. The egress
>> > gateway computes the SAMs based on differentials. So, lets say it
>> > receives the INVITE with 1555, then the INVITE with 155512. It then
>> > sends two SAMs, the first with 1, the next with 2. Lets say, then, that
>> > the INVITE with 15551 comes. Based on CSeq, the egress gateway knows
its
>> > old and rejects it.
>>
>> This is in principle correct (just taking into account that one SAM can
>> contain both digits). But here we have a PSTN-SIP-PSTN situation, and we
>> are trying to achieve ISUP transparency. So, the normal behaviour of the
>> e-gress gateway is to generate the ISUP messages contained in the MIME
>> body of the SIP message.
>
>I disagree with the goal you state. SIP is not a transfer protocol. Our
>aim is for ISUP transparency in the sense that there is no loss of
>information. This can be accomplished through straight transfer of ISUP,
>or by allowing for reconstruction of a complete message from the SIP
>information. Both approaches achieve transparency. In order to make
>operation of the protocol as broadly applicable as possible, I would
>strongly recommend including ISUP messages in bodies only when (1) it
>provides information that cannot be otherwise reconstructed from SIP
>itself, (2) the semantic of the ISUP message matches the semantic of the
>SIP message. In this case, the gateway can reconstruct the SAM.
>Including it only makes things confusing, since, as I pointed out, the
>SAM that is generated may not be the same as the one in the INVITE
>itself (this happens when messages are misordered). In fact, inclusion
>of SAMs doesn't pass either condition above. The SIP INVITE is a
>complete call setup request, akin to IAM, rather than a notification of
>additional digits, as SAM is.
>
>-Jonathan R.
>--
>Jonathan D. Rosenberg                       200 Executive Drive
>Chief Scientist                             Suite 120
>dynamicsoft                                 West Orange, NJ 07052
>[email-masked]                     FAX:   (732) 741-4778
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Nov 1999 09:27:11 -0500

> response something like ???? - uhm I'm not sure!!!)

Why INFO? Usage of INFO for carrying overlapped signaling is definitely
an interoperability problem. Normal SIP UAS's won't know to look for
digits in INFO to set up a call. The example call flow I gave in email
handles perfectly well the case of PSTN-IP-PSTN with overlap on both
ends.

In another mail, you wrote:

> Thinking about it, my feeling is that as Jonathan originally described his
> scheme it is a bit over proactive about sending new dialled digit
> information.  Perhaps it should only send a new INVITE once it has received
> a response to a previous INVITE.  If it receives additional dialled digits
> in this time, then it just accumulates them.

What I don't like about this is that it requires every proxy or UAS to
know about overlap signaling. This is because they need to know to send
a 484 to ask for more digits, which nearly all UAS won't. 

I also don't believe we necesarily need ONE way to handle this. The
ingress gateway can do one of several things as a local choice without
breaking interoperability. Any one of the following will work:

1. send digits immediately upon receipt, as I described in my email
2. wait some timeout T after a digit, and collect whatever arrives
during T into a single INVITE
3. wait for some longer timeout to get all the digits, effectively
converting overlap to en-block at the ingress gateway
4. wait for a # key

Fortunately, it doesn't matter what the ingress gateway does, so long as
the following rules are obeyed at a UAS:

1. A UAS that is not a gateway, which receives an INVITE with a Request
URI that does not correspond to one of its configured addresses (be it a
tel URL or SIP URI), MUST respond with an error response.

2. A gateway that receives an INVITE with a Call-ID that matches a
previous call, and whose Request-URI contains a tel or SIP URL with
additional digits in the user part, should tret this INVITE as adding
additional digits to the original dialed string (overlap).

Note that, if we don't do overlap in SIP at all, (2) does not need to be
supported in a gateway. I believe this is effectively what Matt is
suggesting.

Proxy processing is the same in all cases, which is how en-bloc is
handled also: longest prefix match against a phone number database. Each
INVITE in the case of overlap is treated independently. A smart proxy
can cache if it likes.

So, I would recommend that we describe the various choices for ingress
gateways, making each a MAY, and be sure to codify/emphasize the above
as MUST.

-Jonathan R.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 22 Nov 1999 13:14:52 -0500

> tel URL or SIP URI), MUST respond with an error response.

Sorry I do not understand the need of this requirement.  I had assumed that
ingress gateway is gathering digits some how (dtmf, PSTN signaling magic, etc.)
so that it can address a SIP INVITE to be sent to atleast one SIP server
providing directory services.  The SIP directory server, would proxy or
redirect the message to subsequent server(s) and/or the final SIP UAS.

How does the message get to the final UAS, past all of the SIP servers
with an invalid user ID?  I assumed that is what you meant by invalid address,
is the digits are incomplete.  Isn't this requirement on the SIP servers in the
middle not the user agent server on the edge?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Nov 1999 14:46:51 -0500

> redirect the message to subsequent server(s) and/or the final SIP UAS.

The "directory services" you refer to might not be based on complete
addresses, and will very likely be routing tables based on prefixes. For
example, a proxy might only have prefixes, and for each prefix, have a
configured next hop. That next hop, in turn, may have longer prefix
maps, and for each of those, additional next hops. The above requirement
is not needed so long as no proxy has a prefix (not a complete number)
whose next hop is a UA. However, it is hard to guarantee that this is
never the case. So, to be safe, thats the requirement. Its worth noting
that I think this should generally be standard operating procedure for a
UA. It shouldn't just always ring the phone for every INVITE it gets; as
a check, it should make sure the INVITE was addressed to itself. 

> middle not the user agent server on the edge?

Since, in SIP, there is no way to tell the difference between a UAS
thats a terminal or a gateway, let alone tell if the next hop is a
proxy, I don't want to impose architectural requirements like this.

-Jonathan R.

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 23 Nov 1999 07:00:55 -0600

Please forgive me for "not getting it", but why can things not be kept
simple along the reasoning by Matt Cannon and others: If an IP telephony
gateway terminates calls to a PSTN network with numbering plans having
different digit string lengths, it can just insert a voice message: "Please
push the pound key when you have finished dialing". Are there any problems
with this approach?

Thanks, Henry

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan
> Rosenberg
> Sent: Monday, November 22, 1999 8:27 AM
> To: Pete Cordell
> Cc: Gonzalo Camarillo; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]