Subject: [Sip] RE: Another comment on the outbound draft

From: "Brian Stucker" <[email-masked]>
Date: Mon, 23 Jul 2007 09:18:11 -0500

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Friday, July 20, 2007 11:31 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Rohan Mahy; Cullen Jennings; [email-masked]; Audet, 
> Francois (SC100:3055); [email-masked]; 
> Jonathan Rosenberg; Gonzalo Camarillo
> Subject: Re: Another comment on the outbound draft
> 
> 
> On Jul 19, 2007, at 10:47 PM, Brian Stucker wrote:
> 
> > Rohan/Cullen,
> >
> > One other comment on the outbound draft... I think a 
> statement needs 
> > to be added to the draft to cover the following situation:
> >
> > Let's say a UAC is registering from behind a NAT. If the outbound 
> > proxy does not support outbound (i.e. does not put 'ob' in the Path 
> > header) then the resulting registration will contain an 
> address that 
> > is likely not reachable by the local outbound proxy after the NAT 
> > binding has expired. The UAC can detect that this may occur 
> by looking 
> > for the 'outbound' tag in the supported header of the registration 
> > response and act accordingly. However, in section 4.2 the 
> text in the 
> > third paragraph on page 15 shows that checking the 
> supported header to 
> > see if outbound processing occurred is only a MAY instead of a MUST.
> >
> > I believe that the UAC must do this checking unless they know for a 
> > fact that their contact address is globally routable (or at least 
> > reachable by the local outbound proxy at all times), and if not, 
> > re-register using their server reflexive address in the contact URI 
> > via STUN or derived through some other means (observation of 
> > received/rport values in the registration response Via header, etc).
> 
> Hi Brian,
> 
> Originally I was thinking that the UAC might not care.  If 
> the UAC already set its Contact prepared for the possibility 
> of both outbound and non-outbound cases, it won't need to do 
> anything differently in its initial REGISTER request.  
> However, the UAC MUST check if the 'outbound' tag was in the 
> Require header (see Adam's note on tags) to see if outbound 
> was applied, so it can add or not add the 'ob'  
> parameter to the UACs Contact URI.
> 
> thanks,
> -rohan
> 

Hi Rohan,

Sorry for the delay in replying.

There's a blurb in section 4.3 (third paragraph) that seems to throw a
possible wrench into that logic... 

	The contact is formed normally in that the UAC uses the IP
address of
   the device (even if the device is behind a NAT).

The section on registrations (4.2) does not state anything in particular
about the content of the Contact URI other than the parameters that are
specific to the outbound draft itself. So, if in general, the
expectation (from section 4.3) is that the contact is composed of the IP
address of the device (wondering why it shouldn't generally be the
contact it registered) and there's nothing stated in 4.2 specifically,
it may follow that the UAC implementation doesn't consider the case I am
raising and is left without a usable registration.

Regards,
Brian

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 23 Jul 2007 09:27:10 -0500

Sorry for the clutter... 

Posting to SIP list (stupid auto-complete feature hosed me).

Regards,
Brian

-----Original Message-----
From: Stucker, Brian (RICH1:AR00) 
Sent: Friday, July 20, 2007 12:47 AM
To: 'Cullen Jennings'; 'Rohan Mahy'
Cc: [email-masked]'; Audet, Francois (SC100:3055);
[email-masked]'; Jonathan Rosenberg; Gonzalo Camarillo
Subject: Another comment on the outbound draft

Rohan/Cullen,

One other comment on the outbound draft... I think a statement needs to
be added to the draft to cover the following situation:

Let's say a UAC is registering from behind a NAT. If the outbound proxy
does not support outbound (i.e. does not put 'ob' in the Path header)
then the resulting registration will contain an address that is likely
not reachable by the local outbound proxy after the NAT binding has
expired. The UAC can detect that this may occur by looking for the
'outbound' tag in the supported header of the registration response and
act accordingly. However, in section 4.2 the text in the third paragraph
on page 15 shows that checking the supported header to see if outbound
processing occurred is only a MAY instead of a MUST.

I believe that the UAC must do this checking unless they know for a fact
that their contact address is globally routable (or at least reachable
by the local outbound proxy at all times), and if not, re-register using
their server reflexive address in the contact URI via STUN or derived
through some other means (observation of received/rport values in the
registration response Via header, etc).

Otherwise, the client may have successfully registered an unroutable
address without realizing it thinking that the connection to the
outbound proxy obviated the need to specify a globally routable address
in the contact URI. The BCP for NAT traversal only points off to
outbound (although the citation is very stale in the draft, along with
the even more stale reference to ANAT as a draft, although it has a more
recent ICE reference) and does not discuss this failure case either. In
fact, it directly washes it's hands of it: 

	[outbound] exonerates the need to manipulate contact header
URI's to represent a globally routable address as 	perceived on the
public side of a NAT.

Regards,
Brian