Subject: Re: [Sipping] draft-ietf-sip-call-flows-05

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Jul 2001 14:27:15 -0400

Here are a few comments on draft-ietf-sip-call-flows-05.

	Paul Kyzivat
	Cisco Systems

3.1.4 Successful SIP to SIP with Proxy failure

After the seven transmisions of INVITE to Proxy 1, a single CANCEL is
sent. While in this situation the CANCEL is probably futile, if it is
going to be sent, shouldn't it also be sent seven times? Example 3.2.3
has a similar situation, and it also shows a single cancel, but in the
text it mentions that in reality 7 cancels would be sent.

I would find it clearer if the multiple cancels were shown.

3.1.5 Successful SIP to SIP through SIP Firewall Proxy

This says that a FW Proxy is being used, and the call flows are
consistent with it being a proxy. But then the text also says:

   In addition to firewall traversal, this Back-to-Back User Agent
   (B2BUA) could be used as part of an anonymizer service

which seems to imply that what is labeled a FW Proxy is intended to be a
B2BUA. Seems like perhaps this paragraph doesn't belong here.

3.1.7 Successful SIP to SIP with re-INVITE (T.38 Fax)

The SDP in this example uses domain names in c= lines rather than IP
addresses. (There are also other examples that do this, but this seems
to be the first.) This is in conflict with draft-ietf-sip-rfc2543bis-03.
Do these call flows intend to be in compliance with that draft?

_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Johnston <[email-masked]>
Date: Tue, 10 Jul 2001 10:30:02 -0500

Paul,

Thanks for your comments.  See my responses below.

Alan Johnston
sip:[email-masked]

> I would find it clearer if the multiple cancels were shown.

I will show the multiple CANCELs on the flow.

> B2BUA. Seems like perhaps this paragraph doesn't belong here.

Perhaps this was based on a misunderstanding on my part, but I always read
RFC 2543 to indicate that a server that modifies SDP could not be called a
proxy and was then a B2BUA.  However, I notice language in bis that
indicates that this is OK.  I will remove this reference to B2BUAs.

> Do these call flows intend to be in compliance with that draft?

I just noticed that as well - I will change the c= lines to be IP addresses
only.  The intent of the document is to make it compliant with bis.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jul 2001 13:25:51 -0400

Comment below.

Alan Johnston wrote:
...
> indicates that this is OK.  I will remove this reference to B2BUAs.

It could be me too - I don't claim to be an expert.

My understanding is that a server is a B2BUA if it accepts incoming
invites and then originates other invites, and that it is a proxy if it
passes along invites without altering the identity of the calls and
doesn't originate invites of its own.

It has never been clear to me exactly what parts of a message a proxy is
permited to alter. Messing with the SDP is one of those things that seem
like proxies shouldn't mess with. (One reason I say this is because the
body could be encrypted with the expectation that only the target server
can read it. Then a proxy couldn't do this.)

I would be interested to hear from a real expert about this. One
possibility is that the call flow you show is perfectly fine, and is an
appropriate action for a proxy. Another possibility is that this should
be done via a B2BUA, and that the call flow should be so altered, with
the FW server terminating the incoming call and orginating another in
the other direction.

	Paul

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 10 Jul 2001 14:56:27 -0400

----- Original Message -----
From: "Paul Kyzivat" <[email-masked]>
To: "Alan Johnston" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 10, 2001 1:25 PM
Subject: Re: [Sipping] draft-ietf-sip-call-flows-05

> doesn't originate invites of its own.

Since a B2BUA is a UAS on one side and a UAC on the other (based on the
bis-03 definition), it completely terminates the session on one side and
originates a brand new session on the other. None of the accumulated
hop-by-hop stuff (e.g. Via and Record-Route) are propagated to the other
side.

> can read it. Then a proxy couldn't do this.)

According to bis-03 (page 4):

   Proxies MAY modify any part of the SIP message that are not
   integrity-protected, except those needed to identify call legs.
   Proxies generally do not modify the session description, but MAY do
   so.

Therefore, a proxy can modify the SDP as long as the message is not signed
OR the signature does not need to be passed on the next hop (which is the
case here).

> the FW server terminating the incoming call and orginating another in

Both the Firewall Proxy (current example) and B2BUA are valid models for
traversing firewalls/NATs.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 30 Jul 2001 18:46:26 +0300

Hello,

> traversing firewalls/NATs.

As you say, both are valid models. However, for a NAT, I would show an
example of a proxy. Sometimes a B2BUA is needed, but if a particular
scenario can be resolved with a proxy instead, it is always better. This
way the session can take advantage of all the good features of the
protocol (full-state in messages, state recovery, etc ...).

However, in the firewall scenario, where the firewall wants to hide the
internal architecture of the network, a B2BUA might make more sense. The
firewall can always act as a proxy and encrypt the stuff it wants to
hide (which would be the preferrable approach), but it seems easier for
implementors to just implement a B2BUA (as opposed to a proxy) instead.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]