Subject: [NSIS] Scenario for IP telephony

From: Marcus Brunner <[email-masked]>
Date: Mon, 18 Feb 2002 03:27:39 +0100 (CET)

I have shortly looked it over David and Co´s draft and found the scenario on 
QoS signaling between PSTN gateways and backbone routers particularly 
interesting.

However IMHO the scenario could be broadend to something like "IP telephony 
signaling server to network QoS signaling" not only including PSTN signaling 
servers, but SIP servers as well. Opinions?

Marcus

-------
Marcus Brunner
Network Labs
NEC Europe Ltd
Heidelberg, Germany

E-Mail: [email-masked]
WWW: www.brubers.org/marcus

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Jim Murphy <[email-masked]>
Date: Tue, 19 Feb 2002 13:27:16 -0800

Marcus,

> servers, but SIP servers as well. Opinions?

If the SIP servers are in the path of the data flow, then yes, otherwise,
I think the SIP servers may have a role as policy servers, for example,
as defined in draft-ietf-sip-manyfolks-resource-03. The media endpoints
of the call would still signal for QoS, however, signaling servers, or close
relatives, may get into the act to authorize requests from routers at the
edge.

Thanks,

Jim

---

From: [email-masked]
Date: Thu, 21 Feb 2002 12:44:58 +0100

> servers, but SIP servers as well. Opinions?

I support the idea to think about SIP needs for NSIS. My guess is that
SIP based services will be the killer app for NSIS. That is why we
should think in priority about what can be asked by a SIP user agent for
making NSIS. Then we will know how to make NSIS well suited for SIP.
For instance, multimedia SIP users usually have two microflows (voice
and video). There is also an idea in SIP/SDP called grouping of media
flows: two micro flows can be used alternative by a terminal, for
example when the access network allows always one voice codec, but not
always a better voice codec using more bandwidth. 
And if the 2 microflow follow the same path, one network can request to
a transit network QoS for these microflows at the same time. 

This lead me to two new requirements for NSIS: it should be possible for
a user to request at the same time two (or more) QoS for two (or more)
microflows (especially if they have the same destination/origination
adresses), or even the same QoS that will be shared by two microflows.

-- 
Alban Couturier
---------------------------------------------------------------------
Alcatel Research and Innovation
Ets de Marcoussis R&I/ULC
Route de Nozay                      mailto:[email-masked]
F-91461 Marcoussis CEDEX                       tel: +33 1 69 63 11 97
---------------------------------------------------------------------

---

From: "Andreas Kassler" <[email-masked]>
Date: Thu, 21 Feb 2002 14:40:02 +0100

----- Original Message -----
From: <[email-masked]>
To: "Marcus Brunner" <[email-masked]>
Cc: "NSIS Mailing List" <[email-masked]>
Sent: Thursday, February 21, 2002 12:44 PM
Subject: Re: [NSIS] Scenario for IP telephony

> making NSIS. Then we will know how to make NSIS well suited for SIP.

I also support the idea that it should be possible to reserve the ressources
for SIP sessions using NSIS. However, there is more out there than SIP.
But I don't like the idea that NSIS should be designed to fit nicely to SIP.
We should rather think about requirements that come from SIP. When you look
at
the manyfolks draft
(http://search.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-03
.txt),
which is the base for SIP - network ressource interaction, it says:

   "A User Agent with an active session that desires to change the media
   flows prepares an SDP message body for the re-INVITE describing the
   desired QoS and security preconditions for the revised media flows
   and the desired directions.  The procedures for the re-INVITE, and
   the subsequent message exchanges, are identical to those of an
   initial INVITE. "

So the idea is to use re-Invite, and update your reservations, when the
sender switches
to new media coding. Having multiple QoS levels per flow would complicate
the things,
because you have to signal to which QoS levels to switch. Nevertheless, this
is then
a question how the QoS parameters look like, that the app requests, either a
single value,
some sort of interval, or a set of intervals.

Andreas.

---

From: [email-masked]
Date: Thu, 21 Feb 2002 16:40:38 +0100

Hello Andreas,

> But I don't like the idea that NSIS should be designed to fit nicely to SIP.

I just propose to the work group a requirement that is useful for SIP
users. But I agree that the NSIS protocol must not be done only for SIP
users.

> some sort of interval, or a set of intervals.

Andreas, I was refering to the SDP fid tag. This allow not to resend a
SIP invite each time your access network capacity changes (typically
when your radio access capacity changes during some handovers).    

Kind regards