Subject: RE: SIP: mandatory Contact

From: "Donovan, Steven R." <[email-masked]>
Date: Tue, 18 May 1999 00:57:08 +0100

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

Donovan, Steven R. wrote:
> 
> What are we trying to solve here, making SIP work through NATs or
> making the record-route/route mechanism work?

Hopefully both.

SRD> I agree that the NAT issue needs to be solved.  However, it seems that
it is a big enough of an issue that it deserves a separate draft and I
wouldn't want the more specific issue with record-route/route held up while
waiting for that draft.

> It seems to me that the former is outside the bounds of the SIP
> specification and that the latter is absolutely necessary.
>
> The handling of re-INVITES from the called UA is a specific case that
> argues for making the contact mandatory in the initial INVITE
> message.  Proxy servers that remain in the signaling path will need to
> be able to differentiate between INVITEs and re-INVITES.  If the
> calling UA is not included in the Route header, then SPS1 from my
> original flows will have no way of knowing that a re-INVITE from B,
> the called user agent, is indeed a re-INVITE.  If SPS1 thinks that it
> is a new INVITE, then it is likely to query a location server to
> determine how to route the INVITE message.  There is a chance that the
> INVITE will get correctly routed, but there is a significant chance
> that it won't.
> 
> Making the Contact mandatory in the initial INVITE and as a result
> included in the called user agents route header will fix this problem,
> as SPS1 can use the presence of the route header as in indicator that
> this is no a new INVITE.

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.

If Contact is only made mandatory in initial INVITEs leaving a UAC, I
think we are all satisfied. It will fix the
routing-of-subsequent-requests-problem and as a bonus a proxy still has
the option to remove the Contact. If a proxy removes or hides the
Contact, it is responsible for correct routing of subsequent requests
based on the information in the Contact header. It may do so in some
ways I described in an earlier mail in this thread.

SRD> I may be missing something here, but I don't see how it fixes the
original "routing-of-subsequent-requests-problem" when the NAT-proxy is
sending the INVITE to another proxy.  The second proxy still has to find the
NAT-proxy.

Other proxies may operate as usual, forwarding the Contact header. I'm
just saying it should not be a MUST for a proxy to forward it.

SRD> Again, I may be missing something but I think that the Contact header
is a MUST for all UAC's whether they be in an end client or an intermediary
proxy.

/Lars

> Steve

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 1999 22:50:34 -0400

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

-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