Subject: Re: SIP: mandatory Contact

From: John Hearty <[email-masked]>
Date: Mon, 03 May 1999 09:39 -0500 (CDT)

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

> Donovan, Steven R. wrote:
> 
> 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.

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.

---

From: Lars Berggren <[email-masked]>
Date: Tue, 04 May 1999 08:27:46 +0200

> break early on if Contact is missing so they fix them per this proposed

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