Subject: RE: SIP: mandatory Contact

From: "Donovan, Steven R." <[email-masked]>
Date: Fri, 30 Apr 1999 14:16:35 +0000

What are we trying to solve here, making SIP work through NATs or making the
record-route/route mechanism work?

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.

Steve

-----Original Message-----
From: Lars Berggren [mailto:[email-masked]]
Sent: Thursday, April 29, 1999 5:48 AM
To: Jonathan Rosenberg
Cc: Anders Kristensen; Hearty, John H.; Donovan, Steven R.;
[email-masked]'
Subject: Re: SIP: mandatory Contact

Jonathan Rosenberg wrote:
> 
> Solutions (1) and (3) seem acceptable to me; neither requires protocol
> changes nor standardization. Note that not having a Contact header, as
> in suggestion (3), may "oppose the suggestion" of a mandatory Contact,
> but thats fine here since an intermediate proxy is still responsible for
> "guaranteeing" that the full routed path is being followed. While having
> Contact is mandatory in an INVITE from a UAC, I not sure having a UAS
> return a 400 response if one is not present is a good idea.

I just thought 'making Contact mandatory' meant it had to be present in
INVITE requests leaving proxies too. If Contact is made mandatory I
think it should be clearly stated that a UAS should not expect it if
there is an intermediate proxy present.

> 
> If we do want UAS's to return 400 when no Contact is present, the proxy
> in (3) could still keep the Contact, but rewrite it to be valid but of
> signficance only to the NAT/proxy. It would also insert itself into the
> Record-Route. This solution is a combination of your (3) and (2).

It will insert itself into the Record-Route if the UAS supports it. If
it does not, I guess it may try to use the rewritten Contact for
subsequent requests, which is not the intention.

> Its worth noting, however, that the Contact headers are just one of many
> problems in these cases where you don't want to assume a globally
> routable IP infrastructure. This SIP NAT will also have to rewrite the
> SDP since the media addresses will be wrong. That seems a much bigger
> pain....

I agree, the media part is a harder problem to solve.

/Lars

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 May 1999 00:19:14 -0400

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

It sounds to me like there is consensus to make Contact madatory in
INVITE and in 200 OK. I still believe a UAS should be prepared to
receive an INVITE without Contact, and a UAC should be prepared to
receive a 200 OK without (in other words, the currently specified
behavior should be used). 

-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: Lars Berggren <[email-masked]>
Date: Mon, 03 May 1999 11:37:02 +0200

> making the record-route/route mechanism work?

Hopefully both.

> as SPS1 can use the presence of the route header as in indicator that

Yes, I understand the problem. But my point is that the Contact has not
have to be present when the INVITE has been proxied.

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.

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.

/Lars