RE: draft-santitoro-rap-policy-errorcodes-01.txt

Sadly, when I put a proposal to the SIP wg that integrated route choice with SIP signalling, it got rejected out of hand in *favour* of the multi-round trip SIP then do RSVP approach that was championed by SIP-DCS. Everything helps when attempting to reduce the post-dial delay to a manageable level, though I would imagine the SIP signalling part would always consume the bulk of PDD time.

However, this draft is good in that it permits early rejection of unsuitable TSpecs – if you don’t have the capacity for a new session, why set the ADPSEC low to reflect this and wait for the called party to reject. Better is to reject it straight away thus saving the amount of Path state installed (and then removed) and then let the caller (software) decide how to handle things.

Mark

-----Original Message-----
From: Weiss, Walter [mailto:wweiss@ellacoya.com]
Sent: Monday, February 05, 2001 2:21 PM
To: 'Dan Romascanu'; Andrew Smith; Santitoro, Ralph [GUAR:1482-M:EXCH]
Cc: rap
Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt

Dan,

A number of studies have been done that describe telephone user expectations. Interestingly enough, these expectations differ greatly depending on the situation (landline vs mobile, local vs international, etc.) I am aware of a specific target, but I don't recall the source. I recollection is vague on this but I seem to recall something like 300ms. Hence my prior concern over back to back H.323/SIP and RSVP negotiation overhead.

regards,

-Walter

> -----Original Message-----
> From: Dan Romascanu [mailto:dromasca@avaya.com]
> Sent: Monday, February 05, 2001 12:57 AM
> To: Andrew Smith; Ralph Santitoro
> Cc: rap
> Subject: RE: draft-santitoro-rap-policy-errorcodes-01.txt
>
>
> Hi Andy,
>
> If IP Telephony is the application, one measure of "quickly",
> "fast", etc.
> would be how much you would allow from a phone user
> perspective between the
> moment dialing ended until you hear the phone ringing ("call
> accepted'') or
> the network returning you a "busy" signal ("call rejected").
>
> Regards,
>
> Dan
>
>
> > -----Original Message-----
> > From:       Andrew Smith [SMTP:ah_smith@pacbell.net]
> > Sent:       Sat February 03 2001 9:59
> > To: Ralph Santitoro
> > Cc: rap
> > Subject:    Re: draft-santitoro-rap-policy-errorcodes-01.txt
> >
> > Ralph,
> >
> > Can you provide some quantitative data here e.g. some units
> and values to
> > go
> > with "immediately", "quickly", "fast" etc. It's hard to
> make the right
> > protocol
> > design tradeoffs with people using such qualitative terminology.
> >
> > Thanks,
> >
> > Andrew
> >
>