Subject: Re: SIP: mandatory Contact

From: John Hearty <[email-masked]>
Date: Tue, 04 May 1999 16:41 -0500 (CDT)

I think we have consensus on the need to make the Contact header mandatory
for both requests and responses.  While it is true this may not help
the NAT problem, it does not make it any worse, and helps considerably
when NATs are not involved.  I therefor propose the authors include
mandatory sending of the Contact header in requests and responses in
the RFC.

 I am learning the philosphy Jonathan recommended of strict send requirements
and gracious receive requirements is a basic Internet philosophy, and
we probabally should follow it.  However, in doing so, I would like to
see proposed solutions to the potential problem this creates.  What does
the last proxy of a Record-Route in subsequent requests do when the Contact
was removed?  Some suggestions previously discussed included passing an
empty Record-Route header, or work more like via headers where the
receiving proxy removes itself from the route and passes the header
on to the next proxy in the list. 

 It seems the NAT-dropping-Contact problem is only one of many potential
problems with NATs, and I invite Anders or anyone very familiar with NATs
to work on a separate draft identifying the potential problems they introduce
and propose solutions.

John Hearty
MCI Worldcom

Date: Tue, 04 May 1999 01:27 -0500 (CDT)
From: Lars Berggren <[email-masked]>
To: John Hearty <[email-masked]>
CC: Jonathan Rosenberg <[email-masked]>,
    "Donovan, Steven R." <[email-masked]>,
    Anders Kristensen <[email-masked]>,
    "[email-masked]'" <[email-masked]>
Sender: [email-masked]
Subject: Re: SIP: mandatory Contact

John Hearty wrote:
> 
>  So are you not concuring with the consensus?  Either Contact is mandatory
> or it is not.  We can't call it mandatory but allow Invites and 200s
> without it, that is contradictatory.  I'd rather have new implementations
> break early on if Contact is missing so they fix them per this proposed
> update to the standard.
> 
> John Hearty
> MCI Worldcom

And the NAT-dropping-Contact problem?

Or do you agree with Mr Donovan, thinking it is outside the bounds of
the SIP specification?

If NAT problems can be avoided when designing protocols, why not avoid
them?

Is there anyone here thinking SIP shouldn't work behind NATs?

After all, I think SIP is the 'conference protocol' that is the best
suited for traversing firewalls.

/Lars

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 04 May 1999 23:43:08 -0400

> on to the next proxy in the list.

In cases where a proxy decides to remove the Contact header, its
basically the proxies responsibility to do something which makes sure
that the call can be correctly routed. It might store, on disk, the
appropriate routing information indexed by the Call-ID, To, From and
CSeq, and replace this information when requests arrive. Or, it might
encode the information in a bizarre Record-Route header. The point is,
its a local decision. A UAC MUST insert a Contact, but by making sure a
UAS can process the request even if its not there, we allow proxies to
play these games as needed.

Perhaps its not a major issue; I don't feel THAT stronly and if the
consensus is otherwise (otherwise being a UAS returns a 400 response
when it receives a request without Contact), fine.

Its worth noting that the problem is only for a UAC that doesn't insert
Contact. If the UAS doesn't insert Contact in the 200, things will still
generally work. The last proxy will get a request with a request URI of
the form: [email-masked]. It can use the same logic it
used to route this in the first place to route it now. With most
location services, this will be fine. Its only with extremely dynamic
location services (like ACD), where it might be misrouted. Plus, even if
it is misrouted, the tag ensures that no other end device will process
the re-INVITE or BYE.

With reverse routing (re-INVITEs or BYE from called party to calling
party), its different. The last proxy (which was the first in the
original call setup) will see a request URI which is that of the called
party, not the calling party (thats because the Record-Route headers
contained various translations of the called parties name). Thus, the
message will be completely misrouted and likely it will return to the
called party, rather than going to the calling party. Thus, it only
works with a Contact in the INVITE, or with a proxy which knows what to
do anyway (see examples above).

-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