Subject: Re: TimeStamp in registration replies

From: Nurit Shenhar <[email-masked]>
Date: Wed, 17 Jan 2001 10:51:34 +0200

Hi Brian

So I guess you agree that the TimeStamp parameter should be added as one of
the choices in ServChgReplyParm. Something like:
   servChgReplyParm     = (serviceChangeAddress / serviceChangeMgcId /
                          serviceChangeProfile / serviceChangeVersion /
TimeStamp )

I didn't suggest to disallow sending the TimeStamp in the registration, I
only said it is not a must. If the MG will re-set it's clock according to
the MGC's response, it's initial clock value has no meaning.

Nurit

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, January 16, 2001 5:14 PM
To: 'Nurit Shenhar'; [email-masked]
Subject: RE: TimeStamp in registration replies

While I agree that the MG should adjust it's notion of time to the MGC,
I don't see any reason to disallow, or even discourage the MG from sending
it's notion of time to the MGC.

Brian

> -----Original Message-----
> From: Nurit Shenhar [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 2:21 AM
> To: [email-masked]
> Subject: Re: TimeStamp in registration replies
>
>
> Hello Christian, Terry and list
>
> We have just came to the same point and found that the
> TimeStamp is missing
> in the response. I think that as there is one MGC and many
> MG's, the MG
> should adjust it's local time to the MGC time. Therefore, the
> TimeStamp
> should appear in the MGC serviceChangeResponse, and is not
> needed in the
> request.
>
> Nurit
>
> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 7:40 AM
> To: [email-masked]
> Subject: Re: TimeStamp in registration replies
>
>
> G'Day Terry,
>
> It does seem something is amiss here. Although I'm not sure
> of the best
> way to fix it. The first mention of timestamp in 7.2.8 specifies "It
> (timestamp) can be used by the responder to determine how its
> notion of
> time differs from that of its correspondent." Which is fine when it is
> sent by one entity (MGC or MG) as the peer can adjust accordingly. But
> if both the MGC and MG send it then who should adjust to what? I think
> if both send it we need a little more procedural text to go with
> ASN1/ABNF change.
>
> The 2nd mention of timestamp in 7.2.8 the sentence you mention seems a
> little bit out of place so I'm wondering if it is a left over.
>
> I agree that something needs to be done but I'm not sure which
> something. Other opinions?
>
> I'll put a place holder for this in the implementors' guide additions.
>
> Cheers, Christian
>
> Terry L Anderson wrote:
> >
> > Christian -
> > I sent this some time ago but got no reponse.
> >
> > Section 7.2.8 of H.248 states:
> > "The TimeStamp parameter shall be sent with a registration
> command and
> > its response."
> >
> > There is a TimeStamp optional in ServiceChangeParm of both ASN.1 and
> > ABNF but it is NOT available in either ServiceChangeResParm
> (ASN.1) or
> > servChgReplyParm (ABNF) so I see no way to include it in the
> > registration response.
> >
> > I do not see any correction to the text or to the ASN.1 or
> ABNF specs
> > for this in the Implementors' Guide.
> >
> > I think that including TimeStamp in the reply is useful as
> it allows the
> > MG to know any time skew as well as the MGC knowing it, but
> it may be
> > difficult to change the ABNF and ASN.1 at this point.  If
> they cannot be
> > changed I think that the sentence should be corrected to say:
> >     "The TimeStamp parameter shall be sent with a
> registration command."
> >
> > through the IG.
> >
> > --
> > ------------------------------------------------------------
> > Terry L Anderson              mailto:[email-masked]
> > Tel:908.582.7013   Fax:908.582.6729
> > Pager:800.759.8352 pin 1704572   [email-masked]
> > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
> > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Jan 2001 16:28:23 +1100

G'Day all,

I don't have any problem adding this to the Implementors' Guide for the
ASN1 and ABNF but I think some procedural text needs to go with it. Can
someone come up with something?

Christian