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

From: "Pete Cordell" <[email-masked]>
Date: Mon, 22 Nov 1999 15:33:13 -0000

Jonathan,

>
>
>Pete Cordell wrote:
>>
>> 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!!!)
>
>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.

When I was writing this, I meant to say something like "INFO or similar
method," but my brain moved on before my fingers caught up, BUT

there is the issue that in the come cases logic may not wish to cut through
the caller to callee media path until there is a 200 OK accepting the call.
This might favour an INFO based method.

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

That's a good point, but I think the condition can be safely reduced to
accepting the 404 (and 604) reason also (and perhaps some others) to
indicate that the address is incomplete.  This would allow proxies to remain
ignorant of overlapped sending.

>
>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:
>

I agree that it can be handled multiple ways, but this does require the
protocol to be up to it.

>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

5. Only ever have one outstanding INVITE request and wait for a success or
failure code before sending another. :)

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

This condition will also apply to any device that wants to provide a service
along the call path.

Indeed, it also applys to any terminal UAS because in the general case you
won't know whether a call will go to a gateway or a stand-alone UAS,
especially with users moving around and using location services.

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

Sounds good - subject to comments made.

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

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

---

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

> This might favour an INFO based method.

Why? These seem orthogonal. We have the whole 183 message stuff to
decide whether to cut through. A UAS isn't going to send a 183 in
response to an INFO, but it will to an INVITE.

> ignorant of overlapped sending.

OK. I'm fine with that.

> failure code before sending another. :)

People have expressed concerns over PDD if this is done. Ideally, I'd
prefer this also.

> This condition will also apply to any device that wants to provide a service

For a call-stateful proxy, maybe. For a normal stateful or stateless
proxy, no. 

> especially with users moving around and using location services.

No. A UAS knows its a terminal and not a gateway. A terminal will never
need to worry about things like SAMs and additional address digits. A
terminal will have a small, finite (usually one) set of addresses that
it is responsible for. Thus, a UAS thats a terminal will end up
rejecting all these INVITEs but the last. If, by some chance, another
one comes, the UAS should reject that also, since the request URI won't
match a valid address at the terminal.

Before we get too much farther, I think we need some more discussion on
the general direction of the solution. I see two directions:

1. The one we've been discussing, which requires all egress gateways to
know about overlap. Terminals, stateful and stateless proxies don't need
to do anything special. Call stateful proxies may need to know about
overlap.

2. Matt's suggestion: convert the overlap to en-bloc at the ingress
gateway with a timeout. Users don't need to dial an extra pound or
anything, but PDD's may be longer. Do we care? If this is legacy
technology that truly is fading away, should we bother to burden new
gateways with it?

Anyone else have an opinion on (1) vs. (2)?

-Jonathan R.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 22 Nov 1999 16:08:04 -0500

> to do anything special. Call stateful proxies may need to know about

I like 1 as it works symetrically and solves the problem of collecting digits
from users on SIP terminals as well as for the from PSTN to egress gateway
case.  As much as I would like to see a new dialing pardigm on SIP phones,
I do not believe that it will work for all installations.

It seems though that an installation could always choose to use the second
solution if desired without impact on SIP whether we support option 1 or
not.  I can effectively do option 2 today on a SIP terminal with a timer for
collecting digits, but I believe the impact on the user is less desirable.  I
believe the impact to the PSTN user coming in via the egress gateway is
equivalent.