Subject: Re:

From: "Matt Cannon" <[email-masked]>
Date: Thu, 18 Feb 1999 11:26:40 -0600

Folks,
	I run into an issue with PSTN interworking to SIP that surrounds the
mapping of (SIP)180 ringing to an (ISUP)ACM message and was wondering
if
someone could validate the issue or show me where I'm going wrong.

The issue revolves around the playing of announcements/tones. In the
PSTN network, ringing/tones/announcements are generated by the
terminating party/platform. In a SIP based environment, from my
interpretation, this is not neccessarily true. Things like ringing
are generaly generated at the originating UAC. I am running into a
problem when the two networks inter-operate. When this happens and
a UAC receives a 180 Ringing message, how does it know whether it
should genrate a 'ringing' to the user or simply pass what is being
received on the RTP path? I tried to show two examples in the
scenarios below.

Scenario #1

Call is initiated from the PSTN through a gateway to User B

PSTN		GW	User B
--------------------------
IAM-------->
		INVITE---->
		<-------100
		<-------180
<--------ACM
		<-------200
<--------ANM
		ACK------->

In this scenario, it is assumed that based upon the reception of the
180
Ringing message that the GW will play a ringing tone back to the
originating
caller. To achieve this, an ACM is sent to open the transmit path
from the
GW to the originating user and then the ringing is applied.

Scenario#2

Call is initiated from the PSTN through a gateway to User B, User B
or more likely the network beteen GW and User B wishes to play an
announcement to the originating party, without generating an answer.

PSTN		GW	User B
--------------------------
IAM-------->
		INVITE---->
		<-------100
		<-------180
<--------ACM
<------------Announcement

The problem with this scenario is how does the gateway understand
that based upon
this 180 Ringing message, do not play ringing but rather pass to the
PSTN what is
beinging received on the IP side of the connection?

The same sequences occur if the oringinating user is on IP or if the
IP network is
in the middle of two PSTN networks.

One possible solution may be the introduction of 18X type response
code that
indicates "Inband Information Available", such that in the
interworking scenarios
the UAC upon reception would pass to the user what is being received
on the media path.
Allowing for a one way media path from terminating to originating
party without an
answer.

Thoughts?

Thanks
Matt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 18 Feb 1999 15:40:10 -0500

Comments below.

> announcement to the originating party, without generating an answer.

Yes, this is a problem.

The problem is that you are allowing the gateway to receive RTP packets
from the "network" or user B before the call is accepted. In addition to
causing confusion as you describe, there is, in fact, a serious security
problem here. If the gateway just blindly accepts media on its RTP
ports, random users in the network can inject audio of all sorts into
the gateway, provided they can guess the port number (1 in 65536 chance,
probably less if you eliminate unlikely and odd ports). Ideally, all
media should be encrypted for privacy reasons; this has the advantage
that unencrypted media (read: media from a party with whom you have not
established a trust relationship) is not played out, eliminating this
nasty attack. 

Now, to establish media encryption for the tones, you must establish a
security relationship with the "network" element that is generating the
tone. So, I would say what we need is to separate the original session
and the "announcement" session as two totally separate SIP sessions. The
announcement session would be explicitly set up from the network
announcement element to the gateway. In this case, your call flow looks
like:

 PSTN            GW      User B    Announcement player
 --------------------------
 IAM-------->
                 INVITE---->
                 <-------100
                 <-------180
 <--------ACM
 
                 <--------INVITE--------
                 ------200 OK---------->

 <------------ANNOUNCEMENT---------------->

                 <----BYE---------------
                 -----200 OK----------->

                 <--------200

The gateway would make sure the announcement session is authenticated,
and only from some trusted set of parties which are allowed to play
announcements.

The advantage of having the announcements as a separate SIp session is
that you can set them up at any time. Consider a SIP payphone - halfway
through the call, the network needs to tell me to insert another 50
cents. This is nearly impossible to do securely without establishing a
separate session for the announcement. It also means the announcements
and actual session can have different media compositions, and that we
can apply SIP services to them for all kinds of potentially neat
services (transfer the announcements to some multicast musak on hold or
something).

This also solves your problem. Since the media for the announcement is
separate from the actual convesation, the gateway will know whether to
pass it back or not.

The cost - additional complexity, and an extra RTT before you can play
the announcement.

For this announcement session to work, we need a way for a SIP INVITE to
be "associated" with an existing or in progress session, so the
recipient knows that its not a new call, and doesn't ring the user.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: "Matt Cannon" <[email-masked]>
Date: Thu, 18 Feb 1999 15:43:12 -0600

Comments below preceded by MJC. Sorry about the missing
subject. Can't believe I forgot it.

Thanks
Matt

Thanks
Matt

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, February 18, 1999 2:40 PM
> To: Matt Cannon
> Cc: Confctrl; [email-masked]
> Subject: Re:
>
>
> Comments below.
>
> Matt Cannon wrote:
> >
> > Folks,

[snip]
>  PSTN            GW      User B    Announcement player

MJC=> I agree with the concept that most media streams
will need encryption, but I am not sure the announcement
player concept fixes the problem. Apply the above
flow to the need for originating user to hear ringing.
If User B is not the actual entity generating the ringing,
but rather is expecting the originating UAC( the Gateway)
to provide the tone, when the 180 is received at the GW,
does GW provide tone or wait for the Invite from the
announcement player? Somehow the gateway will need to
understand that in this case the 180 really doesn't mean
ringing but rather wait for the announcement player.

Take this a step farther. If User B is actually accessed
through a terminating gateway in the following scenario.

PSTN		GW-A       GW-B    User B
------------------------------------
IAM-------->
		INVITE---->
                       IAM-------->
		<-------100
                       <---------ACM
		<-------180
<--------ACM
<----------------------------------Announcement

How could you invite an announcement player in
this sequence? GW-B would need to recognize the
announcement is happening(DSP resources?) and somehow
work a sequence to Invite an announcement player
into the flow. Then, how do you decide what
announcement to play?
At the same time, since GW-A does not know what
GW-B is, GW-A is in  a quandary, play ringing or
wait for the Invite. This could get real interesting.

I guess where the trouble starts is what does a
180 Ringing response really mean when inter-working
with the PSTN is encountered and how should a
UAC react upon reception of one?

> recipient knows that its not a new call, and doesn't ring the user.

MJC=> I like this concept of being able use separate sessions for
announcement and see where it could be very useful. I just don't
think it fixes the problem.

---

From: Anup Rao <[email-masked]>
Date: Thu, 18 Feb 1999 15:18:42 -0800

Jonathan Rosenberg wrote:

[SNIP]

> established a trust relationship) is not played out, eliminating this

Here is another way one could do it. The caller can choose to require
the "inband-info" feature. If it supports the feature, the callee can
choose to return a session description  with the 180 Ringing response.
In effect, the voice-channel is  "connected" but the call itself is not.
On receving such a 180 response, the caller treats it as
"alerting/ringing" with inband info(that is received on the RTP port).
Securing the inband info is no different from securing the voicepath, in
this case we just do it earlier.  All of this is non-standard behaviour,
which the caller must  signal by including a Require: header with an
appropriate extension name in the INVITE request. A proxy would see the
header as well.

Pros that I can see :

a) Simple, and deals(I think :) with security issues.
b) Helps PSTN interworking, which is the problem mentioned here.

Cons :

a) What happens if you received 180 Ringing from more than one
destination if the INVITE is forked ? Again, I dont think this is any
different from receiving a 200 from multiple destinations. 
b) You need a Require header, so one would need an extra RTT for callees
who dont support the extension. Arguably, this could be avoided by
caching or configuration on the caller.(ie the caller "knows" that it is
calling a PSTN gateway that will likely support it).

Clearly, this is not as powerful as your suggestion. Some comments below

>  PSTN            GW      User B    Announcement player

This is a very good point. It also re-underlines the issues for and
against an intermediary in the network having control over the data
stream. 
 
Here's a thought : The intermediary can send tone/announcement data
packets to the callers RTP port. The only thing we need is for the
caller to expect data from a different source address/port pair(and that
source only). If we had a way to signal that, things should work out.
This should be possible if the call signalling went through the
intermediary in the first place(which it should). The intermediary could
use a new method with the same Call-ID. Assuming that method is
ANNOUNCE:

caller---> INVITE ----> P ----->INVITE callee
....
caller<--- 200 OK <---- P <-----200 OK callee
(data flowing to/from caller<-->callee)

caller<---ANNOUNCE--- P
caller---->OK-------->P
caller<---announcement data --- P
Presumably the caller inserts the extra 0.01 cents(since calling is now
almost free :)
caller<--- END_ANNOUNCE---P

(data flowing to/from caller<-->callee)

> The cost - additional complexity, and an extra RTT before you can play

The complexity could be quite high. An additional port pair, and some
multiplexing/mixing if the tone/voice are actually sent over to the
PSTN. Yes, it is a tradeoff between features and complexity, but
doubling the port requirements per call seems excessive to me.

-Anup.

---

From: Anup Rao <[email-masked]>
Date: Thu, 18 Feb 1999 17:25:33 -0800

> appropriate extension name in the INVITE request. A proxy would see the

Realizing belatedly that this is somewhat cryptic... here is what I am
proposing:

 What we need is to mimic cutthrough of voice path(one way) on ACM or
Alerting in the PSTN. We invent a feature/extension called
"Inband-Info". The caller signals its availability of this feature(and
hence desire to perform voice cut through before connect) by including
the header "Require: Inband-Info" in its INVITE request. The callee is
forced to either perform the feature(extension) or  reply back with a
5xx. If it does support it, it will include a session description with
the 180 Ringing response if it wishes to send Inband information such as
ringing. The caller, on seeing this 180 response will do the right thing
ie. cut through voice and perhaps send a ACM on the incoming side. In
effect, we will have what the PSTN has -  since voice is cut through
before the call is actually connected.

Eg.

A-->B
INVITE .....
Call-ID: ...
CSeq:...
Require: Inband-Info
Content-Type:

B--->A
100 Trying
....

B--->A
180 Ringing
Content-Type
Content-Length

{sdp desc}

<-----Inband info packets

B--->A
200 OK
Content-Type
Content-Length

{sdp desc}

A-->B
ACK
...
<------DATA------>

Another option, as John Hearty pointed out is to simply use another 1xx
code such as "1xx Inband-Info". The only problem with this is backward
compatibility, since an existing implementation will not treat it as
"Ringing". Using an extension is better because this requires specific
behaviour not expected of all SIP implementations, but mostly
PSTN-gatewaying ones.

-Anup.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 18 Feb 1999 21:11:34 -0500

Unless you encrypt all audio streams (and the RTP header, naturally),
this DOS problem exists during 180 as well as "regular" calls. In either
case, a client can refuse packets from any source not in the SDP c=
description, as long as the receive port there is equal to the source
port of the voice packets. An attacker would now have to guess where
packets might be coming from, so it has to have access to the GW-client
network path, which seems far less likely.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Feb 1999 00:02:55 -0500

This reduces the likelihood of attack, but is still not using real
crypto do it.

The other problem with this solution is that it eliminates the
possibility of RTP terminal mobility, where the source IP address/port
may change.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 Feb 1999 00:46:36 -0500

> ringing but rather wait for the announcement player.

Good point. I think there are a number of separable problems here:

1. How to handle, at a UAC, multiple 180's and/or announcement INVITE's.

2. In the phone network, ringback is sent from the remote party through
the backwards voice path, in addition to there being an ACM message. In
the IP world, the ACM equivalent (180) serves as the signaling message
and as a means to generate ringback. This inconsistency is what is
really causing the problem.

To handle problem (1), the terminating gateway or IP device should
either send a 180, or use this reverse INVITE procedure, but never both,
to avoid the problem.

To handle problem (2), a terminating gateway should probably only use
the reverse-INVITE path procedure. The reverse-path INVITE itself can
trigger an ACM if the calling side is a gateway, since it is effectively
an indication of a ringing. So, the procedure would be like this. When
an INVITE arrives at a terminating gateway, it sends an IAM to the PSTN.
When an ACM arrives, it sets up a reverse path using an INVITE for
announcements. The reception of the INVITE at the calling gateway
triggers an ACM, and if the calling side is not a gateway, no ACM is
sent, of course. The terminating gateway sends anything from the PSTN
over this backwards path. When the call is accepted, the terminating
gateway sends a 200 OK, tears down the reverse path with a BYE, and
sends everything over the normal channel when the ACK arrives. This
approach has the advantage that announcements from the PSTN are
preserved, whereas if it uses the send-180 approach, these tones are
lost. This is anyway not a big deal 99% of the time, I would guess.

When the terminating device is not a gateway, it can either send a 180
as currently specified, or follow the same procedure described above.

Anup's suggestion to put SDP in the 180, but have it be secured I think
still has some problems. First, you can't do the post-setup
announcements. A general solution that does both would seem preferable.
Second, I think there might be cases where the caller is going to get
confused about who is sending what audio when there are multiple 180
responses. This is because it all comes to the same UDP port at the
caller. So, when audio arrives at that port, who is it from? You need to
know in order to decrypt, interpret PTI numbers, etc. This is *not* a
problem for multiple 200 responses, since the ACK contains an updated
SDP, probably with a new port for each callee being ACK'ed. The callee
is not supposed to send audio until the ACK arrives, so there is no
confusion.

In general, I prefer being explicit about what is going on. Putting SDP
into the 180 is trying to set up multiple SIP sessions when there is
really only one.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 Feb 1999 09:45:12 -0500

> possibility of RTP terminal mobility, where the source IP address/port

I should have qualified this statement: a receiver should take packets
from a valid IP address, identified in the SDP c= item *or* a known
SSRC. The latter rule allows mobility (except where the sender moves
before ever sending anything), but still prevents attack by third-party
audio packets.

---

From: Lars Berggren <[email-masked]>
Date: Fri, 19 Feb 1999 16:56:10 +0100

Hi,

Re-reading the SIP spec I found in Table 5, section 6, that the Route
header field is listed as 'not applicable' for ACK requests.

Is this really the case? I can't see why and would appreciate if someone
could explain it to me. I'd regard the Route header field as applicable
to ACK requests as to any other request.

Thanks, Lars.

-- 
Lars Berggren       <[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: "Matt Cannon" <[email-masked]>
Date: Fri, 19 Feb 1999 12:13:21 -0600

comments inline..

Thanks
Matt

> Sent: Thursday, February 18, 1999 11:47 PM
> To: Matt Cannon
> Subject: Re: 180 to ACM Mapping
>
>
> Matt Cannon wrote:
> >
> >
MJC=>
Actually this scenario works out for every call that terminates to
the PSTN network. I recognize the functionality of the solution and
its utility beyond just the ACM inter-working issue, but with the
introduction of an extra 'reverse-Invite/reverse-Bye" sequence
to manage the inband tones, do we not effectivley double the
number of transactions required to complete this call? My
thinking is that this is overhead would not be necessary if
the terminating UA could send a 183(Inband Info) in
cases where it expects to send tones to originating UAC
and a 180 ringing when it expects the originating UAC
to provide the tones.

---

From: Anup Rao <[email-masked]>
Date: Fri, 19 Feb 1999 11:35:18 -0800

> is not supposed to send audio until the ACK arrives, so there is no

The caller starts reading packets only after it receives atleast  the
first 180 response. Then it knows what source to expect and accept
packets from. It will need to CANCEL the other INVITE attempts. Clearly
not as clean with sending n ACKs with different ports in the parallel
case of receiving N 200 responses, but workable, and pretty similar to 
the way the callee can move and start trasmitting packets from a
different location. One cannot provide inband-alerting info from N
destinations anyway. Yes, there is a problem that N destinations might
send 180 responses, and then start sending inband information until they
are sent a CANCEL. (To avoid that, we can specify that INVITEs with this
extension should not be forked, and put in a Proxy-Require as well. Or
retain the forking feature and deal with the problem by ignoring the
packets).

Going by the "reverse INVITE" method, an endpoint that forks an INVITE
can then get N reverse INVITEs. The intention is to provide inband info,
so it cannot really accept all of the INVITEs, but is going to have to
pick one. This makes it very similar to the 180-session desc case. 
(Even if the intention was to accept all, this implies that the endpoint
can mix appropriately which it may not.). If we decide to go the
"reverse INVITE" way, I think it should still be protected by a SIP
"Require:" header, rather than be the base behavior since it will
involve an additional header or other means to relate the two SIP
sessions.

As far as post-setup announcements are concerned, such announcements
from the callee are handled in the voice path setup for the call - it is
really post-setup announcements from a network intermediary that we are
concerned about. I think there is a fundamental choice here :
Do we want call it the same SIP session or not ? If yes, that saves some
signalling, a roundtrip and ports. Do we want to use the same port at
the caller - I would argue that this keeps things simple. I also
believe, that fundamentally there is only one SIP session - so we should
not be creating two. A network intermediary that has been privy to the
call setup signalling can be provided with a way to tell the caller to
now expect an announcement from another address(as in my earlier email).
Using another codec(that the caller advertised in its INVITE or ACK)for
the announcement is possible as well, though arguably less caller
friendly. Also, a network intermediary may want the announcement played
from a RTSP server - providing a means to tell the caller to accept
packets from another address(the server) will deal with this as well,
and will hide RTSP signalling from the caller.

I am not proposing creating 2 SIP sessions, rather :-

a) Using an extension mechanism to separate voice-cutthrough and call
connect. This mirrors the PSTN behavior.
b) Using a new method(or perhaps another 200 response) for a trusted
network intermediary to tell the caller to accept RTP packets from a new
source in the same SIP session.

In summary, I think "reverse INVITE" is elegant but I find it a little
difficult to accept the overhead.  I am trying to save that with a 
little more complexity in terms of logic - using a SIP extension helps
limiting it to clients that anticipate need for it.

-Anup.

---

From: Anup Rao <[email-masked]>
Date: Fri, 19 Feb 1999 11:40:50 -0800

Matt Cannon wrote:

[SNIP]

> number of transactions required to complete this call?

Agreed. I think the overhead is high.

> My

If backwards compatibility is an issue at this (early stage), a client
that does not understand 183 will treat it as a generic 1xx(which as far
as I know is not "180 Ringing"). 
Also, note that the terminating UA needs to send the session description
so that the caller UA knows the source address/port pair. I think we may
be better off protecting the behavior and the 183(inband-info) with a
SIP Require: header.

-Anup.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 20 Feb 1999 02:09:22 -0500

Anup Rao wrote:
> packets from. It will need to CANCEL the other INVITE attempts.

Hmm. CANCEL is not branch-specific. When the client sends a CANCEL, it
cancels every branch that has not yet responded with a 200, which in
this case is still all of them. Perhaps we can hack around this too; it
seems that the INVITE-resp-ACK is exactly what is needed here, though.

 Clearly
> destinations anyway.

Not in parallel, but sequentially, yes. One can envision the case where
each proxy generates some announcements, forwarding the INVITE only
after the announcement has played.

> If we decide to go the

Agreed.

> now expect an announcement from another address(as in my earlier email).

This means you can't use real security, since a network intermediary
will not know the media encryption key. 

<philosophy source="personal">
>From a higher level perspective, what we are grappling with is that the
PSTN model does things in a certain way, which is at odds with the way
it would be done in an IP environment. Thus, the best way to achieve
compatibility and transparency with the PSTN is to mimic exactly the way
it works in the IP world. I think there is an increasing trend in
development of IP protocols in this direction. What you end up with is,
well, the PSTN all over again. It is transparent since it works the same
way and basically does nothing more, nothing less. This is both good and
bad at the same time - the true opportunities with IP telephony, I
believe, lie where it can do better and different things. But, I fear
that placing higher value on transparency of service will kill these
opportunities.
</philosophy>

> limiting it to clients that anticipate need for it.

I agree the overhead is higher. I agree it does not mimick how it is
done in the PSTN. I understand that the 183 "Inband Info" would allow us
to do what is more like the PSTN. I'm still not conviced it works, and
that we won't sacrifice the ability to do real security. Also, in the
long run, if we need to add additional things to handle other scenarios,
a more general solution (thats more complex) might be simpler than the
sum of many simple hacks.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Feb 1999 00:46:06 -0500

Anup Rao wrote:
> so that the caller UA knows the source address/port pair.

Does it? If the purpose of the 183 is just the backwards voice path, the
SDP in the INVITE is sufficient, since the caller isn't sending
anything. The SDP in the response is needed to get the ports, addresses
of the announcement server.

 I think we may
> be better off protecting the behavior and the 183(inband-info) with a

Doesn't work. You can only place Require: in a request. What happens if
the caller doesn't support 183? It can't send a response anyway, so the
announcement server won't know whether the 183 is understood independent
of whether or not Require: is included. 

This here is an example of a server-feature, where it is the server that
is requesting a feature from the client. Require and Proxy-Require are
for where the client is requesting a feature from the server. Handling
server features is much harder. 

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Feb 1999 00:54:03 -0500

> to ACK requests as to any other request.

The intention is that they are permitted in the ACK requests. 

-Jonathan R.

---

From: Anup Rao <[email-masked]>
Date: Mon, 22 Feb 1999 08:51:11 -0800

> of the announcement server.

I proposed that so the caller can know the source to accept packets
from, as well as send RTCP. This prevents it from accepting packets from
just anywhere.

> > be better off protecting the behavior and the 183(inband-info) with a

Apologies, I wasnt quite clear here. I meant that the new status code
would be allowed and have the same meaning as "Ringing" only if the
request(hence the entire INVITE transaction) would be protected by
"Require:".

> server features is much harder.

Yes, agreed. That is precisely the reason I proposed it the way I did,
and said "the client can choose to require the inband-info feature".
Ideally, it should have been the other way around. This  assumes a good
guess(and/or clever configuration) at the caller end, or as a worst
case, an extra roundtrip if the callee does not support it.

-Anup.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Feb 1999 12:00:58 -0500

> from, as well as send RTCP. This prevents it from accepting packets from

This presupposes that the SDP connection line indicates the source of
the packets. Its purpose is not that - it indicates where the caller
should send the packets to, not where it will receive them from. In many
cases, the IP address will be the same, but for multi-homed hosts,
multicast, or for cases where another server is streaming the media,
this won't be the case. Furthermore, the port number in the SDP will not
be the source port number of packets from the callee to caller. I'm
still uncomfortable about hacking in security in this way. As such, I
think it deserves attention about how to add real crypto security.

The SDP in the 183 can contain a key line. If this response is encrypted
with the private key of the caller (known from the response-key tag) and
signed by the callee, the caller can obtain a key for the media to
receive from that user. Now, when media arrives at the callee, it can
apply de-cryption, run a validity check, and if its valid, start playing
the audio. If there are multiple 183's, or even a 183 followed by a 200,
there can be confusion about whom the media belongs to, in order to know
which key to apply. This is why the ACK is nice - the caller can specify
a different port for each. In any case, I suppose the caller could
compare the source IP address against a cache, where the cache contains
(IP address, key) pairs. If a packet shows up with an IP address not in
the cache, all keys are tried, and whichever yields valid RTP packets,
that IP address/key pair is put in the cache. This way, we don't depend
on the IP addresses in the c line of the SDP for identification. 

Comments?

-Jonathan R.