SIP Interim Working
Group Meeting
November 7, 1999 – Washington, DC
10 am – 7 PM
DCS Presentations
The morning was focussed on understanding the DCS proposals with discussion deferred until the afternoon.
Distributed Call Signaling (DCS) &
Dynamic QoS Architectures
K.K. Ramakrishnan – presenter
Agenda
IP Telephony: Opportunities
Packet telephony & intelligent end terminals coupled with adequate bandwidth (especially access) provide tremendous opportunity
Take advantage of data and voice for an enhanced user experience
Enhance our service provider role
IP disintermediates the service provide
how does the service provider play a role, and derive revenue?
Key POINT: service providers want a role in which they can derive revenue
DOSA – Distributed Open Signaling
Architecture Framework
Protocol Specification Efforts in PacketCable
CableLabs supports an activity to rapidly develop standards for services over cable
major push now to standardize IP telephony
Initial effort was to provide support for simple phones for consumer telephony: multiple lines per subscriber based on SGCP limited to using the constrained user interface, provide traditional telephony
Separate distributed call signaling protocol exploiting intelligence at end-points, address needs of providers.
separate dynamic QoS protocol based on supporting per-flow resource management on access network
Attempted to focus on minimizing the extensions to SIP and rather re-interpret how it is used.
Extensions to SIP
Privacy was considered a big issue.
Layered Architecture
Layer 2: DOCSIS
Layer 3: common services
Layer 4: protocols for telephony and other future functions
HFC Media Capabilities
Primary Ring – few hundred thousand homes
Primary hubs to SH – few tens of thousands of homes
SH – few hundred homes
DOCSIS 1.0 Media Access Protocol
cable modem requests access to transmit a certain amount of data – requests using contention slots
CMTS schedules modem transmission and sends down a map on downstream channel
modem may piggyback request
CM waits for request interval and transmits request frame asking for mini-slots
The CMTS signals the mini-slot grant in a succeeding MAP message.
DOCSIS 1.1 Enhancements
Support for isochronous service and real-time polling
Support for fragmentation of packets
DOCSIS 1.1 introduces "unsolicited" grants
CM/MTA negotiates with the CMTS to have a periodic grant of a certain size – admission control performed on the request to provide isochronous service
CMTS allocates grants to CM/MTA periodically
dddd
A CMTS signals the partial mini-slot grant in a MAP message.
The CMTS signals the remaining mini-slot grant in a MAP message.
SOURCES OF DELAY
G.711: 80 bytes at 64 Kbps è 10 ms packetization delay
Sources of delay
RT delay: typical backbone 96 ms
10 ms packetization results in 199 ms.
Concluded that 300 ms is desired so just make it with this system
There was some discussion about worst case compared to average case and that the worst case analysis may not be useful.
Conclusions: can barely support the required demand using this system. They are concerned with both delay and capacity and manage those resources carefully.
Service Providers Requirements
DCS Architecture
Enhances SIP with carrier class features
Tight coupling between call signaling and QoS control
Care taken to ensure untrusted end-points behave as desired
Signaling Performance Requirements
Stateless proxies were discussed. They are slightly different than as used in the SIP documents
Dynamic QoS Framework
Network considered to have multiple segments
Each segment performs its own resource management, using protocols most appropriate for segment
Access network likely to be resource constrained
Use per-flow signaling and allocation, on a c-by-c basis, in concert with call-leg manipulation
Backbone network resources may be managed differently
Two-phase resource management
Have resource before ringing, but enable billing only after far end picks up
Gate controller is responsible for allocating and managing the resources
Gate Control Architecture
Gates in edge routers opened for individual calls – call admission control and policing implemented in edge routers
Gate controller manipulates a gate after call setup is authorized
- setting up gate in advance of reservation request allows a gate controller to be stateless
MTA makes a resource reservation request by signaling to edge router
Accounting info stored at the edge router to generate usage events
Example Call Flow
MTA issues an INVITE. The DCS Proxies perform gate control function and setup the gates to allow the appropriate flows for the calls. The 200 OK from the destination completes causes the gate controllers to finalize the flow filters in the gates. This sequence is for authorization.
Resource Management: 1st Phase
Resource Management: 2nd Phase
How do proxies know that the second INVITE is related to the first INVITE and insure that the INVITE goes to the right proxies? The speaker indicated that it doesn’t have to go through the same proxies and that this will be discussed in a subsequent portion of the presentation.
What does the second INVITE contain? The same information, with an incremented sequence number.
Resource Envelopes
Authorization of resource usage done at call setup; exercise policy at gate controller, "authorized" envelope
Later, capability negotiation enables end-points to reserve resources
End-points commit to use resources when far end picks-up
Using RSVP for Segmented Resource Allocation
Client sends path message directed towards far endpoint
CMTS intercepts PSTN message
CMTs reserves bandwidth on DOCSIS link
Backbone resource management ensures capacity available for call
On successful reservation, CMTS sends RESV message back to client
Minimal changes to RSVP: destination of PATH is destination of data
There was some comments raised that this method does not guarantee that the far-end reservation is performed. It is expected that the far-end endpoint will issue its own resource reservation.
There is also provision for additional PATH/RESV sequence on the terminating side, if there are conventional routers involved.
Extensions to RSVP
Bi-directional bandwidth is reserved with one PATH/RESV pair
Resources identified explicitly
Managing changes in resource usage during a call
Two-phase resource management support
Support included for resource reservation within the customer LAN
Summary
DOSA introduced the concept of integration QoS with call signaling
DCS call signaling allows use of end-point intelligence to support new services and integration with other applications
DCS proxies not required to be involved throughout the call
Dynamic QoS provides the common underlying framework of QoS
Basic SIP/DCS Call Flow
Bill
New headers:
Caller, Anonymity, Stage 1
Caller
This is used rather than From: because the proxies cannot change From: field.
The caller field is a MUST. The originating proxy server does not use the From: field in anyway. The number is required; the name and any other information are optional.
Anonymity
Verifies that the header is present
State l
Insures that resources are set aside as described above
Proxy headers:
Gate, billing-info, billing-id
Anonymity: Off
DCS proxy server (terminating) modifies the value of the DCS caller header based on the type of privacy requested by the calling party
Removes the header from the message
Gate:
Terminating DCS proxy passed to gate controller for controlling resource allocation
Billing-info
Header saved – needed when subsequent transaction response is received
Removes the header from the message
Single service provider issues focussed on. Multiple service provider scenarios have not been specifically addressed
Billing-ID
Header saved
Removes the header from the message
Terminating proxy – T-MTA
New headers: State
State:
User agent server saves the value of state so that it can be used to invoke services related to this call (e.g., call trace, call transfer).
200 OK uses standard SIP from to CMTA to dpt
A Gate id is inserted into the 200OK by DPt to the DPo
Gate, State headers are inserted to 200OK by DPo to the Mat
ACK end-to-end
Stage 2 is the standard SIP INVITE
standard 180 ringing
standard 200 ok
standard ACK
standard 200 ok
standard BYE
Standard RSVP release mechanism is used to release resources
How is the resource level usage information synchronized with the proxy information? The edge routers perform the usage monitoring by generating events. Proxies generate the information for the edge routers to actually perform the billing functions.
Integration of Resource Management and
Call Signaling for IP Telephony
Bill Marshall
(This was the most contentious at the last IETF meeting.)
High Speed Data Service vs. Telephony
Service
Telephony Service over IP Networks
Service Provider must implement Policy Restrictions on RSVP
How about if only telephony subscribers can do the RSVP?
How about if RSVP required per-call authorization?
To achieve current telephony billing model.
It appears to AT&T that billing models must continue to support capabilities for international settlement policies that are currently in existence.
Call Blocking vs. Call Defect
Does the 0.00001% apply to cellular telephony as well? Carriers do not like to report failures to the FCC, so they want to minimize those failures. The rate at which the failures need to be reported lead to determination
Major defect concerned about is when the resource reservation failure after the call has been notified.
Prevention of Call Defects Vs Theft of Service
When to allocate resources needed for the call?
Can we charge customer for the time the phone is ringing?
Can we trust the customer to tell us when called party answers?
Theft of Service is a Major Problem
Customers have access to High Speed Data Service
Access is via box within customer premises
Via a box that we encourage others to program
Experience with Cellular phones, Set Top Boxes, etc
Expect the box in customer’s home to do exactly what is in the customer’s best interest to do, not what is in the network or service provider’s interests.
Examples:
Can we trust the customer to tell us when called party answers? No.
Can we place a time limit on ringing?
Other alternatives?
Conclusion: we only give the resources for the connection when the endpoint says call answered. This is when we commit the resources.
But, what if called party says they answered, but calling party (payor) didn’t?
But what if calling party (payor) says to disconnect, but called party doesn’t?
If two cooperating users place calls to each other, each getting a few half-calls.
Theft of Service, Conclusion
Must have a control point inside the trusted network to police requests
Must limit packets to only the destination authorized, and limit bandwidth to only the amount authorized.
Must coordinate with the control point at other end of connection.
Basic Requirements for Resource Management
Two-stage Resource Reservation
Post-Pickup Delay Requirements
Post-Pickup Delay – Voice Path
|
0 |
called party answers Assume 20ms delay of MTA access of upstream |
|
20ms |
MTA sends Commit message to Edge Router Assume edge router schedules QoS in 4ms |
|
24ms |
Edge Router schedules QoS and sends MAP |
|
30ms |
First payload packet sent by MTA |
|
|
Assume: 40ms one-way delay across network |
|
70 ms |
First payload packet received by call originator |
Post-Pickup Delay – Signaling Path
|
0 |
Called party answers Assume 20ms delay of MTA access of upstream |
|
20ms |
MTA sends 200 OK message to its proxy(1) Assume proxy load 80%, avg. queue of 4 msgs, 10ms of processing for a request, 5ms for a response: delay=35ms |
|
55ms |
Proxy(1) sends 200 OK to Proxy(2) Assume 33.3ms transmission delay Proxy-Proxy |
|
88ms |
Proxy(2) receives the 200 OK The number of proxies relates to the number of security associations. Assume 4 proxies |
|
123ms |
Proxy(2) to Proxy(3) |
|
192 |
Proxy(3) to Proxy(4) |
|
260ms |
Proxy(4) to endpoint |
Clipping Choices at Call Originator
What is the call originator to do when receiving payload before the 200-OK?
Call Setup: Fundamental Requirements
First INVITE must go through proxies for authorization/translation
Resources must be available prior to ringing destination phone
Answer must go direct, not via proxies
DCS messages and relationship to resource reservation
Invite across network
IP return information
Resource reservation
Message to cause ringing
Ringing
Called party off-hook: 200 OK (answer) end-to-end
Single-stage Alternatives Examined
Invite (w/reserve)
100 trying includes SDP for forward direction media
RSVP initiated from both ends for reservation
resv-ack requested by destination
180 ringing when all resources available
may clip voice
Conclusion: Need for two-state INVITE
Invite (stage 1)
200-OK
ACK
RSVP
Second INVITE causes alerting
A knowledgeable proxy can convert from one style to another
Two-stage calling single-stage INVITE
invite (stage 1)à invite(w/reserve)
100 trying becomes 200-OK
ack absorbed
180 ringing absorbed
second invite passed through
180 ringing will be sent again
Potential race if answered quickly, may lead to clipping
Single-stage calling two-stage
Can also be interworked
Potentially may be clipped
Additional header in initial INVITE message
Call Authorization and Quality of Service
K. K. Ramakrishnan
A shortened version was presented in order to give an overview of QoS RSVP handling to IETF. It may or may not be a part of an ID to IETF in the future.
GateSet message sent from CMS/Policy Server to CMTS/NE in order to install destination MTP address and authorization envelope. They use COPS for this. The information from the 200 OK SDP portion is sent to the Gate and some information about the Remote Gate.
RSVP_PATH+ to destination MTA
The message contains information that is sufficient for both directions. Originating MTA issues a PATH message to the destination MTA, but the CMTS intercepts it and compares against the authorization envelope.
RSVP Usage Enhancements
All enhancements use opaque objects that work with traditional RSVP routers.
rspec has to be carried with rsvp_path
The reverse direction RSVP information has to be carried with the RSVP_PATH
The PacketCable QoS spec includes detailed information regarding reservation
CMST signals the success
RSVP__RESV+: the message contains information that is sufficient for one direction only.
This also happens at the terminating side as well.
If two-way reservation is necessary at CPE routers
RSVP Routers between MTA and CM: RSVP_PATH is needed.
The message contains information that is sufficient for one direction only.
This PATH message is used for dealing with traditional routers that handle unidirectional resource reservation.
Before sending media stream, the MTA commits the bandwidth
The MTA sends COMMIT to CMTS. The message contains information that is sufficient for CMTS to resolve which reservation is to be activated.
The COMMIT can look like a RSVP to reserve other resources.
CMTS signals the gate commit to remote end.
The two edges communicate directly to identify that gates are opening and that they are coordinated. The remote gate information is required to perform this edge-to-edge commit. This is done via a GateOpen command.
This is to protect against some theft of service scenarios in which two half-calls are created. The flow is opened and a timer set awaiting response from the far GateOpen message.
GateOpen from both ends causes COMMIT_ACK.
For call release, endpoint generates a standard PATH_RELEASE message. A GateClose message goes between the gates to ensure that the gates are again closed.
After release of the resources, a signaling BYE is sent.
Afternoon session
Michael Manette – 3Com
Detailed call flow information
Billing-Info: information added to the DCS-Proxy
DCS-Proxy does not propagate redirect responses
Multiple billing-info headers can be added to identify that the call legs may have different billing-info.
Collect Call: may not be solved in this version. In the message headers, the terminating proxy can override the billing info in the 200 OK. It is believed that the hooks are there, but there are no details provided in any of the specifications at this time.
SIP Extensions for Caller Identity, Privacy, and Operator Services
Fleming Andreason – Telcordia
Calling Identity – PSTN
Calling Identity Items
Terminating switch must be able to identify calling party, e.g., for call trace
Calling Identity Delivery services allow the called party to obtain calling identity information about the calling party
Calling Identity Delivery Blocking (CIDB) features allow the calling party to control the presentation of calling identity items.
Calling Identity – SIP
These fields apply to the INVITEs for Stage 1.
INVITE: encrypt From header field to maintain privacy
Caller: John Doe; 555-1111 – calling name and number, as provided
Anonymity: calling num
Proxy(1) normalizes the caller number.
Proxy(2) implements the privacy function by inserting "Private" into the Caller header to the t-MTA.
Privacy – other issues to consider
From – may be encrypted; set display-name to anonymous before forwarding to User Agent
Contact – point to anonymizer
Via – may be encrypted or removed statefully by proxies
Call-ID – should not be based on endpoint’s IP-address
SDP – several fields include IP-address and user information, e.g., owner
RTCP – some messages may include user information, e.g., name
Question raised about the validation (i.e., screening) of calling numbers. The correspondence to ISDN is that the From: header corresponds to a user-provided and unscreened number. The caller field is guaranteed valid like the Calling Party Number parameter in ISUP. These are guaranteed by the DCS Proxy.
Supporting Operator Services
Fleming presented an MF operator flow that indicated use of BLV.
The MG is designed to detect the transmission tone from the operator system and the MGC re-invites with the EI call.
The flow indicates that the BLV and EI requests are made to the T-MTA. There could be security issues related to reliance on the endpoint to provide the functionality required to implement the BLV/EI functions.
Distributing Call State to Endpoints
Poornima Lalwaney – General Instrument
Managing State
Storing state at end points
Achieving Call Features with stateless proxy using state header information
Call Transfer – Illustration of the user of
State Information (Blind without consultation)
Uses the INVITE (also, replace) construct from proxy to proxy to O-MTA, rather than the BYE construct that the I-D on call control proposal. This information
The receipt of the INVITE at the O-MTA, it triggers and INVITE(stage1) message for the transfer call.
DCS-State and HTTP Cookies
http uses cookie for state management/as a handle to pass session context change from server to client
missed the DCS version…
A comparison was made between DCS-State and HTTP cookies. It appears that the HTTP cookie is a superset of the STATE required for the DCS-state. At this time, it does not appear to be useful.
Question: Does the state information capture the anonymity information and presentation restriction information? Yes. This may be used to restrict its use in call return.
JR thanked associates from PacketCable for presenting the material from their DCS proposal.
Discussion
Chair: DCS presented a set of requirements. The WG must decide if we need to support these requirements. These drafts, then, provide proposals for implementing those requirements.
Henning: Let’s formulate some goals and agree on those.
One of the architectural ideas of SIP is to avoid the buy-it-all or you get nothing philosophy. Can the proposed material be considered orthogonal items for use by particular users when needed? Can we as a group do this division up front so that things don’t depend on each other?
Text protocols have no style guide, but it would be good to keep syntax styles regular across the different headers rather than completely new methods for each one.
Try to leverage some of these ideas for things which do not have the same architectural assumptions as presented here, but share some of the same requirements.
If we want to avoid some of the protocol problems, we should always assume that we are in a heterogeneous environment and not require multiple layers of translation. We may also want to have a system that may want to use AT&T super duper service or 7-11 style off-the-shelf cheap service.
Response (KK):
All of these are good principles. Started looking at it as one integrated framework. They have tried to separate out pieces step-by-step as it evolved. This lead to writing separate drafts on these topics. Interworking with SIP is desired, but details have not been worked through. They wanted to begin with something solid first, but will work on that as well.
Scott Petrack:
The requirements are that the system act, look, feel like the PSTN. SIP was not designed with these requirements particular in mind. It should be kept in mind that some of these things may not be necessary longer term and maybe could be retired. We should not be forced to do things in the future that we don’t need to.
David Oran:
There was a conscious effort to study the user model of the PSTN and see what the user expects of the system. An assessment should be made to determine if anything was done just because it is implemented that way in the PSTN. These items should be removed. What should remain are the user expectations.
Response (KK):
A focus was made on regulatory requirements and how these reflect what societal expectations are.
Scott Petrack:
If you have an internet terminal, some of the requirements may actually change.
Johnathan Rosenberg:
Tons of really good ideas here. Leveraging the experiences of these experts is tremendously valuable. Can we think about how to generalize the feature or requirements to solve more problems? For example, the state or cookie concept storage in the terminals is a good idea. Can this be generalized? This does introduce some good reliability. It would be great if we had some general privacy and other mechanisms that expand beyond telephony.
Lawrence Conroy:
With BLV, you don’t need actually need to determine if there is an RTP stream. Maybe can send them to a voice announcement unit.
Response (Bill Marshall):
There is a desire that there is some listening to meaningful information on the voice line, not just presence of information.
JR: wants to make a more general system
?: Security implications. Could this be broken into easily?
?: There are also limitations because the SDP doesn’t include source ports. How can the gate filters handle this? It seems that there could be problems with systems that use this capability.
Two-phase INVITE process: Would it be reasonable for a call within a call method? That is, perhaps embed a reservation request into a SIP message. This proposal wasn’t too clear.
What about services that have multiple contact addresses? If redirect responses are blocked by the proxies, then the we have problems. The forwarding services should be implemented using call forwarding proxies rather than removing capabilities such as specifying an HTTP URL in a redirect that user may want to utilize.
The TEL: URL is becoming common usage. Could this be utilized for some of the LNP processing rather than a LNP field in the SIP URL?
Why you can’t charge for general RSVP reservations? User expectation is that billing starts when the called party picks up the phone. In fact, billing models with different codecs and silence suppression have different requirements. Different requirements related to amount of data transmitted may be necessary. Per minute model may not be a long-term requirement. You need to encourage billing that will enable optimization of services.
Response:
The issue of charging is for what is for reserved. Charging for holding of resources is what service provider might wish to charge for. Will allow for the capability for RSVP to determine what is being billed for rather than what is actually being used.
Differentiation between what is reserved and what is used is necessary from a user perspective.
Henning:
Do we want to have different strengths of resource reservation? If so, these are handled by on a stream by stream basis. These should be addressed by RSVP extension.
Response:
The mechanisms are in place to know when the different aspects occur: reservation occurs, usage begins, usage ends, resource is released. The mechanisms are defined so that any billing model can be implemented based on these items.
Two stages of the invitation –
Is the two stage necessary? It is difficult to coordinate the gate opening to be within 100ms is the problem. If this gate control was necessary to that degree, then two-stage method is not necessary.
JR: Does the clipping problem get solved within 100 ms in the PSTN today? If not, why are we trying to solve it better here? Is it acceptable to use best effort traffic for the 100 ms until the QoS effort kicks in?
Response: 70% upstream traffic is reserved for voice traffic.
JR: Best effort voice in the reverse direction may be sufficient then. But, cable access technology notes that best effort packets take significantly more time the
Response: Jitter buffering causes a problem. Clicks may occur when the buffer adapts.
?: Tying in of SIP signaling and QoS control is extremely necessary. Good work. MCI has proposed some similar mechanisms using policy control at the edges of the network. The MCI proposal does differ significantly for the 2-stage invite.
Question: How does the network based proxy work when the second INVITE goes directly to the endpoint? Doing this two-stage process, how does the proxy server get back into the call? How does the endpoint request services from proxies?
Response: It was intended that the proxy gets out of the call as soon as possible.
Issue: This may be constraining.
More discussion: how does the endpoint know how to invoke a feature of a proxy in this scenario? For example, How do I record that a BYE event occurred?
Response:
two-stage invite addresses the blocking issue
the direct response 200 ok is meant to solve the clipping issue
Clearly Resource Allocation is useful to tie to the call signaling. The other is a separate issue.
Reliability of data in the MTA is an issue. It would be probably be desired to have a method of having a network store for things that are critical such as for call trace.
Proxies, endpoints. There is no reason that the service provider could not provide some of these storage capabilities in a proxy.
If we divide the state information into the state required for active calls vs. state that you must have between calls. This information between calls may be useful for the service provider to maintain. There is a different fate sharing model for between calls as during calls.
Anonymity:
There are certain mechanisms in place already for the honest people. Maybe its more efficient to certify existing information rather than replace the information. Treat these as exception condition rather than removing capabilities that we already have. If you have reason to believe that the information cannot be verified, then include an XXX-sender not verified header. This is recommended to maintain backward compatibility with existing systems.
What happens next?
JR: What requirements there are and what do we want to support? This did not come clearly out of the discussion. General consensus is known on some of the items, but not all. After we reach agreement on the requirements, then we work the particular proposals.
Note: Many of the ? mark comments were generated by Dean Willis. One or two by Steve Donovan (I think). However, I cannot identify them now.