Subject: RE: SIP: mandatory Contact

From: "Donovan, Steven R." <[email-masked]>
Date: Fri, 21 May 1999 14:43:57 +0100

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, May 17, 1999 9:51 PM
To: Donovan, Steven R.
Cc: Lars Berggren; Anders Kristensen; Hearty, John H.;
[email-masked]'
Subject: Re: SIP: mandatory Contact

> Donovan, Steven R. wrote:
> 
> Yes, I understand the problem. But my point is that the Contact has
> not
> have to be present when the INVITE has been proxied.
> 
> SRD> I don't understand why a proxy should not be able to include a
> contact header in a proxied INVITE message.  I also think that
> removing this requirement for the proxy re-introduces the same problem
> that caused this discussion in the first place.
> 
> SRD> If the proxy that you are talking about is a NAT then why should
> it not be able to include a Contact header.   I understand that it may
> not be the same as the original Contact header.  It should probably be
> contain the URI of the NAT/proxy server itself.  The NAT will be
> saving state for the session anyway, so it should have the ability to
> map the NAT contact header with the original contact header.

The Contact in the INVITE is only needed to route the "last hop" from
the first downstream proxy back upstream to the caller. Proxies and the
UAS don't need to see a Contact. All thats needed for them is a Route
header pointing to the next hop. So, I see no problem if a firewall
removes the Contact (and perhaps some Record-Route headers), so long as
it places a Record-Route for itself in the request, and so long as it
knows how to reconstruct the Record-Route and Contact headers it
removed, when needed. The only hardfast rule is that a UAC/proxy must
always ensure that the next hop, and previous hop, can route requests to
it. This is what mandates insertion of the Contact by a UAC.

SRD> OK, I'll agree that it will work if the firewall removes the Contact
with a couple of provisos.  First, it complicates the called user agent in
that it will be building the Route header for subsequent requests.  With the
stripping of the Contact header, the called user agent will need to
understand that it includes the contents of the Contact in the Route list if
present and doesn't throw-up if it is not present (I agree that it is a
small complication).  Second, it needs to be clear that if the firewall
strips the Contact header then it MUST include a Record-Route header with
its identity.  And finally, I don't understand why the firewall wouldn't add
a new Contact header, replacing the one that it stripped, but this is a
personal preference that I can ignore based on the greater wisdom of the
list.

---

From: Lars Berggren <[email-masked]>
Date: Fri, 21 May 1999 16:44:55 +0200

> Donovan, Steven R. wrote:
...
> 
> SRD> OK, I'll agree that it will work if the firewall removes the
> Contact with a couple of provisos.  First, it complicates the called
> user agent in that it will be building the Route header for subsequent
> requests.  With the stripping of the Contact header, the called user
> agent will need to understand that it includes the contents of the
> Contact in the Route list if present and doesn't throw-up if it is not
> present (I agree that it is a small complication).  Second, it needs
> to be clear that if the firewall strips the Contact header then it
> MUST include a Record-Route header with its identity.  And finally, I
> don't understand why the firewall wouldn't add a new Contact header,
> replacing the one that it stripped, but this is a personal preference
> that I can ignore based on the greater wisdom of the list.

If the firewall replaces the Contact header (with its own address), it
has to keep some sort of state in order to route subsequent requests to
the correct destination.

This works fine, but I believe there are ways for the firewall to
reconstruct the Contact header that does not require state.

For example, as I suggested earlier in this thread, a firewall could
encrypt/encode the address of the Contact header to be removed and
insert it in a Record-Route header before inserting its own address.
This way no state is required in the firewall for routing of subsequent
requests.

/Lars

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 May 1999 10:54:52 -0400

> present (I agree that it is a small complication).

More importantly, it needs to do this already, since Contact is not
mandatory in RFC2543.

  Second, it needs
> that I can ignore based on the greater wisdom of the list.

The firewall might add a Contact header, sure. The point here is to be
flexible for receiving. This would allow the proxy to do what it needs
to do, and be sure the UAS still behaves correctly.

-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