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

From: Rohan Mahy <[email-masked]>
Date: Sat, 1 Dec 2007 09:32:36 -0800

Hi Brian,

I think this is now addressed in outbound-11 with the following  
comment in section 4.2:
> If the registrar did not support outbound, the UA may have  
> unintentionally registered an unroutable contact. It is the  
> responsiblity of the UA to remove any inappropriate Contacts.

thanks,
-rohan

On Jul 23, 2007, at 7:18 AM, Brian Stucker wrote:
>> -----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