Subject: Re: SIP: Forked request

From: "Scott Petrack"<[email-masked]>
Date: Wed, 8 Apr 1998 07:15:35 +0200

Looking at my own notes, I don't see if any resolution was given to the
"forked request" problem.  Could someone remind me please?

As far as the SIP spec goes, I believe that there are only two
possibilities:

a. A client of a single unicast SIP request needs to receive a single
unicast response. It is the responsibility of the callee's servers
(whatever combination of proxies and user agents there are) to ensure that
the client issuing an INVITE will not get multiple responses.

b. A client of a single unicast SIP request might get multiple responses,
in which case it is the responsibility of the client to decide whom to ACK
and how to proceed.

I find the second possibility very strange personally, but maybe it could
work. In any case I feel quite strongly that there are many different
behaviors that are reasonable, and that since by definition the proxy
server is a proxy for a particular user, the user needs to decide what s/he
wants. IPTel is going to give us a solution for how a human user can
program his/her proxy server to do what s/he wants.

---------------------------------------------------------
Jonathan wrote:
> Clearly the *natural* behavior would be to create a multiparty call,
> but I just don't see any reasonable way to accomplish this.

I do. Apparently this requires that the server forking the request have
what Mark calls "user agent functionality" or "SIP/SIP gateway
functionality" -- the server sets up some sort of RTP mixer or translator,
mucks about with the SDP, and generally makes sure that the client which
sent the INVITE stays happy. The SIP spec does not need to be altered in
any way for such a gateway.

Igor wrote:
>I feel that the caller (not callee) should decide if he/she wants to
>talk to a single person or to everyone who answered the call - only the
>caller knows the intention of the call, after all.

This certainly is not what happens in the current phone system -- when you
call my house you might have two people answering two different phones, and
there's nothing you can do to prevent it. To enable Igor's desire that the
"caller can decide" we might want to allow possibility b above -- in the
example of my house phone, a caller might send a single unicast INVITE, and
get multiple OKs from different users, but each one would have identical
SDP, and in the end all users would be using a single multicast group
address for all audio.

Bottom line -- the SIP spec needs only to specify which of possibility a or
b above (or both) is allowed.

Scott

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 08 Apr 1998 09:56:00 -0400

> the client issuing an INVITE will not get multiple responses.

Doing this is actually much harder than it seems. The difficulty is that
there can be a large number of forking proxies, and several clients
which may receive several requests each from different proxies. To
return a single response back to the client, a forking proxy must
essentially BYE any "extra" 200 OK's it receives from multiple callee's.
With multiple proxies and callees, its not too hard to construct a
scenario whereby all callee's end up receiving BYE's, so the entire call
is cancelled.

> in which case it is the responsibility of the client to decide whom to ACK

I believe this makes sense and it solves many of the race problems
above.

> any way for such a gateway.

True; this can work if the proxy always sets things up to act as a
mixer. It must always modify the outgoing SDP in proxied SIP requests to
indicate the address and port of the mixer, not the caller.
Interestingly, if multiple proxies do this, I believe it will correctly
set up a tree of cascaded mixers, with no loops; very nice property.

An even more desirable behavior would be to have a proxy only set up a
mixer when multiple 200 responses come back. This can be made to work
with a few very small changes to SIP semantics:

1. You don't send media until you receive an ACK,
2. An ACK can contain an SDP which "updates" the one in the original
INVITE

So, it works as follows. A proxy receives an INVITE, and it forks it out
without changing the SDP. The proxy then waits for all responses to its
forks. If there is one 200, this is relayed back to the client and a
normal point to point call proceeds. If there are multiple 200's, the
proxy can either relay all of them back, else it can act as a mixer, ACK
the 200's on its own, but include its own address/port in the ACK's. It
then returns a 200 OK to the client, and includes its own address/port
in the 200 OK.

> b above (or both) is allowed.

I agree we should absolutely keep it as flexible as possible, but under
the constraint that we have basic correctness.

-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: Christian Huitema <[email-masked]>
Date: Wed, 8 Apr 1998 10:31:01 -0400 (EDT)

The robustness principle mandates that SIP agents should be ready
for the worst case.  This means that, if a request generates several
responses (the worst case) they should be ready to deal with it.
The obvious way is to ACK one, then BYE the others.  More elaborate
ways may involve redirection to a muxing server or to a multicast
address.

SIp agents can obviously help by not creating a gratuitous worst case.
For example, if Scott's house has multiple telephones, then it could
use a local multicast group (the equivalent of the current bus structure
of the electrical wire), and then appear as one wire to the outside world
(i.e. one unicast address).

By the way, this points to an ambiguity in RTP requirements.  SDP
announces the address (unicast of multicast) through which an agent
is ready to receive RTP traffic.  But RTP allows the muxing of
several flows on a single address / port pair.  Can we assume that
all RTP implementations are ready to accept an arbitrary number
of audio (or video) sources ?

-- 
Christian Huitema
----------
See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 08 Apr 1998 13:56:23 -0400

Jonathan Rosenberg wrote:

> 1. You don't send media until you receive an ACK,

You shouldn't do that in any event...

> then returns a 200 OK to the client, and includes its own address/port

While this is a possible solution, it does raise a few problems:

- encrypted message bodies (hard)
- authentication (solvable)
- ACK/BYE bypass via Location:

Note that this assumes that the proxy knows what the right answer is:
namely, "reach first" (or "reach one") or "reach all". Currently, the
"Call-Disposition: all" header calls for the server to aggregate all the
200 responses into a single "multiple choices" response and then let the
client decide. 

If the client C gets back 200 responses from callees A and B, it
probably should contact an MCU explicitly:

INVITE MCU
Also: A,B
Call-ID: same as before

> the constraint that we have basic correctness.

It seems we have three correct possibilities:

- fork and forward 200 as they come and let the client decide
- don't fork, return 300 if there are multiple choices
- aggregate 200s and step in as an MCU

Allowing the ACK to contain a "final" session description is useful for
asymmetric media (and RTCP ports) in any event.

-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 732 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 14 May 1999 16:37:05 -0500 (CDT)

>You have a SIP Redirect Servers that demands authentication for INVITE
>requests.
>Now consider the following using UDP for transport:
>
>(1) a UAC issues an unauthenticated INVIVTE to the Server.
>(2) the server responds with a 401
>(3) the UAC sends authenticated INVITE to the Server
>(4) the server sends a provisional 100 response
>(5) the servers sends a final 3xx response
>(6) The client sends an authenticated ACK to the Server

It is worth noting that, between steps 2 and 3, the UAC should send
an ACK to the server.

>Now what is the correct behavioural of the Redirect Server when:
>
>* the client sends and unauthenticated ACK in step (6) ?

This one is the tough one.  Owing to the purpose of the ACK, I'd 
think that there is no harm in accepting the ACK despite its lack
of authentication.

The only "attack" on this type of security is if someone tries
to send an ACK in your stead. (Perhaps to screw up codec negotiation?)
Anyway, to do this, they'd have to be sniffing packets. Without
putting some sort of challenge in the final 3xx response , the
 authentication string will be the same one that you sent in step (3),
which the snooper would have been able to capture anyway.

So, requiring authentication for ACK messages does not seem to
buy you any security at all.

>* the client sends an unauthenticated BYE or CANCEL at anytime
>between (3) and (6) to the server ?

BYE isn't valid before the INVITE transaction is complete.

If they send an unauthenticated CANCEL, reply with a 401.
In fact, accepting an "authenticated" CANCEL without a
new challenge raises the same snooping issues as ACK does,
so this should be the normal case.

(1) a UAC issues an unauthenticated INVIVTE to the Server.
(2) the server responds with a 401
(3) the client send an ACK to the server
(4) the UAC sends authenticated INVITE to the Server
(5) the server sends a provisional 100 response
(6) the UAC sends an unauthenticated CANCEL to the server
(7) the server responds with a 401
(8) the UAC sends an authenticated CANCEL to the server
(9) the server responds with a 200

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 May 1999 23:19:06 -0400

> think that there is no harm in accepting the ACK despite its lack

For a redirect server, this is probably OK. The ACK doesn't have any
codec stuff in it at all, since we're not talking about a UAS. It only
causes response retransmissions to cease.

> which the snooper would have been able to capture anyway.

Only true for basic and digest. PGP is much better, since the signature
is over the entire message. With PGP, the only thing thats possible, I
think, is a replay attack of a previously sent ACK. This would appear as
a duplicate ACK to the UAS. Entirely harmless.

However, if a UAS accepts non-authenticated ACK's, attacks are possible
which can cause misrouted media, since the ACK can contain SDP.
Therefore, a UAS which is doing authentication probably should only
accept authenticated ACKs. It has no choice but to ignore
unauthenticated ACKs, which I think is fine.

> BYE isn't valid before the INVITE transaction is complete.

BYE doesn't make sense to a redirect server. But, it is allowed (and
makes sense) to send a BYE to a UAS before the transaction is complete.
CANCEL is more to terminate searches, BYE is to hangup. 

> so this should be the normal case.

I'm not sure you can provide a new challenge for CANCEL. Unlike INVITE,
each proxy generates its own local response to a CANCEL it receives, and
then forwards it. Thus, lets say UAC A calls through proxies P1 and P2,
towards UAS B. When A sends a CANCEL, P1 sends a 200 OK, then forwards
the CANCEL to P2, which sends a 200 OK to P1. P2 then forwards it to B.
If B responds with a 401, the response is not forwarded back towards the
caller, since P2 has already responded. So, since CANCEL is really part
of the same transaction, I think it should be based on the same
challenge as the INVITE. If it fails at a UAS, its just ignored. The
only reason it could fail is if its a malformed, malicious or errored
packet; this is because the UAS should use the same challenge for the
entire transaction (in other words, for http, a correctly behaving
client must expect a 401 for any request to the same server. This is
because the nonce it was assuming has expired at the server. However,
since a UAS maintains state (whereas a web server normally does not), it
keeps the nonce for the duration of the transaction).

There is an interesting problem, though. Since the authentication is
done only at the UAS, its possible for someone to spoof a CANCEL. Proxy
servers won't know that this is a spoofed CANCEL, and so they CANCEL the
call. If the CANCEL "beats" the original INVITE to the last proxy before
the UAS, and the last proxy doesn't forward the INVITE since it got the
CANCEL before it forwarded the INVITE, the the called party won't ever
hear the phone ring. This would allow an attacker to stop someone from
making calls. Of course, if the INVITE gets to the UAS before the
CANCEL, there is no problem, since the CANCEL will fail authentication
and be ignored.

The fix for this is to make sure proxies don't do this. A proxy which
receives an INVITE, and then a CANCEL, should still forward the INVITE,
and then send a CANCEL for it straightaway. This is probably what most
servers will do anyway (I know mine will). 

-Jonathan R.

---

From: Christian Huitema <[email-masked]>
Date: Sat, 15 May 1999 12:04:03 -0400 (EDT)

Jonathan, Jens,
Accepting unauthenticated command that change the satus of the connection
is a bad idea.  Once you request authentication, you should get it for
all commands.  Otherwise, third parties that somehow can get or predict the
content of messages would be able to hijack or dlete calls. 
The real choice is between silent discard and error messages.  I think
that we should define the error message, but give the option to not
always send it, in prticular when the responder feels being flooded or
being used for a weird denial of service attack.

-- 
Christian Huitema
------------------------------
Please note my new address: [email-masked]
http://www.telcordia.com/

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 17 May 1999 10:14:16 -0500 (CDT)

>being used for a weird denial of service attack.

In the case of unauthenticated ACKs, though, this doesn't make sense.
SIP says that a server /must/ not send responses to an ACK.

/a

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 8 Jun 1999 17:01:57 -0500 (CDT)

The current draft for multipart bodies for SIP messages 
(<draft-ietf-mmusic-sip-multipart-00.txt>) appears to limit
bodies to, at the maximum:

1) One section with session information (e.g. SDP)
2) One section for telephony signalling transparancy (e.g. ISUP)
3) One section for billing information (e.g. OTP)

Given that each message is bound by an MTU when using UDP,
this may not be a bad thing; however, there seem to be a few
cases when it would be beneficial to include multiple ISUP messages 
in a single SIP message. For example, when the ingress gateway
is performing overlap dialing "analysis" by waiting for an
inter-digit timeout, it will potentially collect an IAM and 
several SAMs before sending out an INVITE. The gateway could just
glom all the digits together and send them in one IAM, but this
seems a bit intrusive: we wouldn't be providing ISUP transparency
per se, as much as ISUP translations.

Similarly, we could take segmented messages and combine them into
a single large message, but this takes extra processing at
both ends.

I realise that, with the INFO extension, the subsequent messages 
could be sent following the INVITE/IAM message; however, this
seems like an unnecessary amount of network overhead.

Comments, anyone? Does this need to be revised/clarified in the
current draft, or should implementations just try to work around
this limitation?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 08 Jun 1999 19:14:14 -0400

> 3) One section for billing information (e.g. OTP)

Agreed. Why limit the multipart at all? Each section is identified by
its MIME type, so they are self-identifying. If that is necessary, a
parameter indicating functionality could be added, but I don't see this,
as the MIME types have non-overlapping functionality. It is not likely
that OTP will suddenly be mistaken for session information.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jun 1999 21:13:16 -0400

> that OTP will suddenly be mistaken for session information.

In fact, I would argue that no extension is needed at all for multipart
in SIP. SIP allows MIME bodies, and since multipart is a valid MIME
type, SIP supports it right now. In fact, multipart/parallel is probably
the right sub-type for what is being done here. As Henning points out,
the MIME type itself would tell a UA what to do with each part. Type
application/sdp is for session description, application/isup for isup
parameters, and application/otp for billing. Eventually, other things,
like application/cpl, may be needed too. Rather than constraining
ourselves by enumerating the specific functions the various MIME parts
provide, leave it to the type itself to indicate.

What you will need is an extension defining the semantics for processing
each type. For example, draft-ietf-iptel-sip-reg-payload defines the
semantics for application/cpl and application/sip-cgi.

-Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 09 Jun 1999 10:49:12 +0300

Hi Adam,

> seems like an unnecessary amount of network overhead.

But if you haven't received yet all the B-number, how do you know where
to send the INVITE?

You could send it to a SIP proxy, but the proxy would have to wait for
the SAMs anyway to reach the proper user... and it would mean that the
SIP proxy understands ISUP (and we do not want this to happen, right? ).

You could also send it to a MGC that will end up in the PSTN network
again, but how do you know which MGC you have to send it to?

By the way, I am probably going to Dallas in a couple of weeks.
See you there,

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 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Jun 1999 09:55:03 -0400 (EDT)

I could agree with Jonathan's proposal to use a generic multipart
type if we solve a few questions:

1) what happens when I receive a multipart that I only partially
   understand?

2) how do I indetify the intent of the sender behind each
   multipart data?

The basic intent of the multipart draft was to solve these two
points.  In fact, different parts may request different treatment:

1) SDP is typically end to end, relayed without changes by "pure
signalling" agents,

2) ISUP is typically "gateway to gateway." It can be relayed by 
   intermediate signalling agents wthout even parsing it.

3) Payment information is typically local.
   It is inserted by "border agents" and removed at the next border.

The advantage of specifying a "sip" multipart type is that you can
specify these behaviors. A genric type leaves them unspecified, which
in effect placesthe burden on "profiles" or maybe on the main spec.
In addition, the existing semantics such as "parallel" may not be
appropriate -- think of the multiple SAM messages example...

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 09 Jun 1999 10:12:15 -0400

> 1) what happens when I receive a multipart that I only partially

This should be specified by a parameter: "reject", "ignore" or "copy".

> 2) how do I indetify the intent of the sender behind each

I mentioned this as another parameter, with sensible defaults for
"well-known" types.

> appropriate -- think of the multiple SAM messages example...

I don't much care whether you call it multipart/sip or
multipart/parallel (it makes no real difference and I agree that the
MIME rendering conventions geared for email readers don't make a whole
lot of sense for a SIP proxy), but the important part is to allow a
multipart with a variable number of components, where each component is
labeled as to the "if you don't understand this" situation. 

Note, however, that even without the "do not understand" parameter, most
situations of interest can be handled by Require and Proxy-Require and
default SDP semantics. Proxy servers copy the payload without further
inspection. If you send SDP + ISUP to a current UAS, it will respond
with a payload error and indicate that it can't accept multipart. If you
want to make sure that the other side does the correct thing with
billing, 

Require: otp

will be sufficient.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Jun 1999 10:36:28 -0400

> 1) what happens when I receive a multipart that I only partially

By partially understand, I presume you mean that some of the multipart
types are understood, and others are not. I think this is easy; the UAS
returns a 415 response, and lists the types it understands. This would
include, in the Accept header in the response, the multipart type
itself, plus the types carried in a multipart that it understands. For
example:

415 Unsupported Media Type
Accept: multipart/parallel, application/sdp

The UAC can then determine what was incompatible and resubmit the
request without that part. This is all standard SIP stuff here.

> 2) how do I indetify the intent of the sender behind each

I believe the MIME type of each part in the multipart indicates the
intent. application/sdp means "I want to set up this session with you",
for example. 

>    intermediate signalling agents wthout even parsing it.

Since a gateway is nothing more than a glorified UA, from a SIP
perspective I don't see the difference between 1 and 2.

>    It is inserted by "border agents" and removed at the next border.

Having a SIP proxy be required to understand and modify bodies, whether
they are encapsulated in a multipart or not, is a bit troublesome. What
does it do if it doesn't understand a body? Should it return an error
with Accept headers? This is really UA behavior, not proxy behavior, and
I can think of strange things that could happen.

That aside, this behavior again can be ascertained from the type -
application/otp would be server to server.

> in effect placesthe burden on "profiles" or maybe on the main spec.

Whether or not you use a SIP multipart or an existing multipart, you
will need to say something about the semantics of what happens when you
get a part of that type. As I mentioned in the last mail, the draft on
usage of application/sip-cgi is an example of what I mean.

> appropriate -- think of the multiple SAM messages example...

Well, if you want to be precise, you could have a multipart/parallel
that carries two parts: one is SDP, and the other is multipart/mixed.
The mixed subpart contains each SAM. The definition of mixed seems to be
more or less what we want:

> The "mixed" subtype of "multipart" is intended for use when the body
>    parts are independent and need to be bundled in a particular order.
>    Any "multipart" subtypes that an implementation does not recognize
>    must be treated as being of subtype "mixed".

-Jonathan R.

---

From: "Adam B. Roach" <[email-masked]>
Date: Wed, 9 Jun 1999 10:42:38 -0500 (CDT)

>again, but how do you know which MGC you have to send it to?

If the SIP nodes do not receive sufficient information in the SIP
request itself (i.e. ignoring the bodies) to route the call, they
reject the INVITE with a "484 Address Incomplete," which should cause
the ingress gateway to collect more address messages and re-send
an INVITE.

What I was talking about above is the workaround where you would send
an INVITE that has, in the SIP portion, a full destination number. In
the encapsulated IAM, it has the first portion of that number.
Subsequent INFO messages would carry the remaining SAM messages.

The point of my earlier mail was that I think this is a particularly
cumbersome method of transporting the SAMs, even though it is a viable
workaround in case the specification doesn't get modified.