OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsn message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AI from telecon Oct 11, 2004 on Parameter Negotiation in telecom call control protocols


All

On today's call, David Hull asked me to relate my experiences with methods and procedures for negotiation of telecom call control parameters.

The main ones I was involved in were: Q.931 ISDN and Q.2931 for ATM/B-ISDN.  There was also an n x 64K b/s version of Primary Rate ISDN where I believe you could negotiate the value of n - which determined the actual bandwidth for the call.   The H.320 video coding standard was based on narrowband ISDN (p x 64K b/s channels) so could exploit such a negotiated rate.

-The ISDN/ATM call control protocols first defined the call attributes/parameters (=Information Elements) that could be negotiated.  These might include delay, jitter, residual error rate, committed information rate/ sustainable throughput, burst rate, burst size. etc. 

-Some of these parameters were end to end (e.g. delay, jitter, error rate) while others only had local significance -from the terminal equipment to the 1st switch (e.g. committed information rate/ sustainable throughput, burst rate, burst size).

-There was no range or set of values requested by the calling party (or the network on an incoming call).  Instead, the caller requested a specific value for each parameter in the SETUP message and if the network could NOT support it, a less stringent/ relaxed value (lower or higher depending on the parameter) was returned by the network to the caller in the next message sent with the same call reference. 

-The caller then could either a] accept the new value and request the connection to be established, or b] reject the call and try again later. There was only one pass at negotiation- no back and forth of offering and counter offerring of parameters. 

Basically, it was up to the network to determine what parameter value it could support at the time of the call request.  If it was not able to support the requested parameter value in the SETUP message sent by the calling party then it would suggest another value that it could support- take it or leave it.

So the message is to keep the negotiation procedure very simple, otherwise it will be too complicated to implement and be interoperable.

----------------------------------------------------------------------------------------------------------------------------------------

Hope this helps.  I will be attending Telecom 04 Conference in Las Vegas: Tues-Thurs of this week, with no access to email.

Best...

alan

 

Alan Weissberger
NEC
1 408 863 6042 voice
1 408 863 6099 fax

--

___________________________________________________________
Sign-up for Ads Free at Mail.com
http://www.mail.com/? sr=signup



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]