Subject: Re: [Sip] WGLC comments on sip-outbound-10: further concerns for registrar

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

Hi Erkki,

I believe I have addressed all your comments below except storing the  
time (which is an issue for GRUU). See inline for more.

thanks,
-rohan

On Aug 2, 2007, at 12:50 AM, <[email-masked]>  
<[email-masked]> wrote:
>
> Hi,
>
> After cleaning up the Section 6 from some apparently
> redundant text I finally got my thoughts focused to
> some aspects of the registrar behaviour defined in
> the remaining pieces of text. Here are the related
> comments:
>
> 6.  Registrar Mechanisms
>
> Minor technical:
>
>    "The registrar MUST be prepared to receive,
>    simultaneously for the same AOR, some registrations that use
>    instance-id and reg-id and some registrations that do not."
>
> Which specific use cases this is expected to cover:
> a) for the same AOR but from different devices; or
> b) for the same AOR even from one single device so
>    that one REGISTER contains reg-id while another
>    does not; or
> c) for the same AOR from one single device so that
>    a single REGISTER would contain multiple Contacts,
>    some of them having reg-id while others not ?
>
> To me the cases b) and c) do not make sense so I suggest
> scoping this statement for case a) as follows:
> "The registrar MUST be prepared to receive,
>  for the same AOR (from different devices),
>  some registrations that use instance-id and
>  reg-id and some registrations that do not."

The registrar could receive from the same UA, one registration  
through a edge proxy that supports outbound, and one that does not.    
(a and b are allowed, but not c).  The case of c) is already  
prohibited by the text in section 4.2.1

> Minor technical:
>
>    "The Registrar MAY be configured
>    with local policy to reject any registrations that do not include
>    the instance-id and reg-id, or with Path header field values that
>    do not contain the 'ob' parameter.
>
> If REGISTER request with mixed type of Contacts is allowed
> (case c above) some text has to be added how to handle such
> REGISTER requests if the proxy has been configured a local
> policy to reject registrations without reg-id or instance-id.
> Shall the registrar reject the whole request or only
> those contacts which are not according to the policy ?

the whole request with a 400 Bad Request, since this combination is  
clearly illegal.

> Minor technical:
>
>    "The registrar MUST store all the Contact parameters
>    in the binding and SHOULD also store the time at which the
>    binding was last updated."
>
>    "and SHOULD update the time the binding was last updated."
>
> Maybe this has been explained earlier, but I did not find
> from the document any reason why the registrar should store
> the time at which the binding was last updated. Why should
> it do that ? At least the time should not be needed for
> replacing earlier registrations with newer ones, which
> is described in section 3.2 like this: "If the instance-id
> and reg-id are the same as a previous registration for the
> same AOR, the registrar replaces the old Contact URI and
> flow information."

As I mentioned in another thread, the time is stored for consistency  
with 3261 and for use with GRUU, but we could change this behavior if  
we update GRUU accordingly.

> Related Nit for Section 3.2:
>
> As pointed out in my earlier email, in my opinion
> the storing the Contact URI is not necessary for Outbound
> so that the section 3.2 should say: "If the instance-id
> and reg-id are the same as a previous registration for the
> same AOR, the registrar replaces the old binding and
> flow information."

The Contact URI is still necessary (for retargeting), but your  
sentence is still correct.

thanks,
-rohan

> Regards,
> Erkki

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Wed, 5 Dec 2007 10:16:34 -0800

Hi,

My comments and a question or two inline.
thanks,
-rohan

On Aug 3, 2007, at 4:20 PM, Francois Audet wrote:
> Some more WGLC on sip-outbound-10
> ---------------------------------
>
> Section 4.4: change "timed-keepalives" to "time-keepalive" (there  
> are at
> least 2 instances of
> this mistake).

fixed in -11

> -------
>
> The example in section 9 should use TCP instead of of UDP, since  
> TCP is
> preferred (as
> discussed in section 14). Furthermore, if the UDP example is used, it
> should show
> the rport parameter in the Via header.

I plan to completely revamp the example and will incorporate these  
comments.

> It should be clarified that the last paragraph of 4.3 only applies to
> UDP.

ok, I added, then accidentally deleted this in -11.  This is now  
fixed in my local copy.

> ------
>
> I would like to see more details in section 9 about how the "ob",
> "rport" and Route and
> Record-Route headers (i.e., including the keep-XXX parameter) are used
> by a UA that
> supports outbound procedures, when sending requests using Outbound  
> (like
> INVITE for example).
>
> Also, it would be helpful to see an example where the outbound  
> proxy is
> not co-located with the Registrar, so we could see how the Path header
> is used,
> including the "ob" parameter (as per the procedures of 5.1). This  
> stuff
> is non-trivial
> and would benefit greatly from an example flow (with the messages
> content).
> Distinguishing between 'ob' in Contact and in Path/Route seems
> important.
>
> In other words, a flow (with messages) illustrating what an edge proxy
> does for both
> registration and for further requests such as INVITE

I am going to completely rewrite the example based on your advice here.

> ------
>
> Finally, the procedures in 5.3 on "incoming" requests is not that  
> clear
> on what it actually
> mean "on the wire". It says the following:
>
>    For an incoming request, the proxy removes
>    the Route header field value and forwards the request over the
>    'logical flow' identified by the flow token, that is known to  
> deliver
>    data to the specific target UA instance.
>
> Does it just mean that the request will be forward on the same TCP or
> UDP flow, and
> that there is no additional requirements?

correct

> Nothing on the wire that will
> show that outbound
> is being used (Is the flow token supposed to be inserted by the  
> Proxy)?

nothing on the wire

> On that front,
> message 8 in the example of section 9 has a flow token, where does it
> come from?
> This is very confusing since the Caller might not use Outbound, so  
> where
> does this
> token come from, and what it is used for in this example? How is the
> token of the
> Callee given to the Caller???

The existing example is wrong in many ways and will be completely  
replaced.

> It is also no clear from the
> example how the Caller knows to reattempt the INVITE to the secondary
> proxy (wouldn't
> this be handled in the terminating side's domain?).
>
> There is no description of UAS requirements in the draft. Does it mean
> that there are none
> whatsoever? (I'm talking about a UAS that is using outbound receiving
> incoming requests). If
> so, there should be a UAS section stating so.

do you think Section 4 should have a separate subsection?  All you  
need to do is leave your flow open and be prepared to receive  
messages over it.

> Is it possible for example that incoming requests might be received by
> the UAS on different
> flows (because of reboot for example)? In the same session??

Yes.

thanks,
-rohan

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 5 Dec 2007 12:39:27 -0600

Trimming all the resolved issues from the email. 

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]] 
> Sent: Wednesday, December 05, 2007 10:17
> To: Audet, Francois (SC100:3055)
> Cc: Rohan Mahy; [email-masked]; [email-masked]
> Subject: Re: WGLC comments on sip-outbound-10
> >
> > Francois:
> >
> > that there are none whatsoever? (I'm talking about a UAS 
> that is using 
> > outbound receiving incoming requests). If so, there should be a UAS 
> > section stating so.
> 
> do you think Section 4 should have a separate subsection?  
> All you need to do is leave your flow open and be prepared to 
> receive messages over it.

I think the procedures for a standards track document makes it clear
that we have to separate the UAS from the UAC from the Proxy requirements.
Yes.