Subject: RE: [NSIS] Scenario for IP telephony

From: [email-masked]
Date: Wed, 20 Feb 2002 15:55:46 +0200

Hi Marcus,

> 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?

This would be difficult.  For any signaling that is not on-path, we
will need to have a discovery mechanism as well as some sort of
URI - something like user@realm - where realm is the home network
of the user. 

I think a better approach is to allow a router to act as a QoS proxy,
and have some additional signaling (to a bandwidth broaker or something
like that) and additionally have some identity for the QoS request,
in case that user needs to interact with a AAA (or similar) mechanism.

John

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

---

From: [email-masked]
Date: Wed, 20 Feb 2002 15:57:00 +0200

Hi Jim,

> 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.

Good point.  

John

---

From: [email-masked]
Date: Thu, 21 Feb 2002 13:47:35 +0200

Hi all,

> 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. 

Just to nip this in the bud, please refer to this document:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-unify-00.txt

My understanding is that this will be incorporated into the SIP-bis draft.
My general feeling is that the UNIFY draft (along with this draft)
http://search.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-03.txt
will be the primary way in which SIP can interact with QoS.

John

---

From: [email-masked]
Date: Fri, 22 Feb 2002 10:41:51 +0100

Hi all,

One thing the refered SIP documents don't specify is the actual QoS to be used for
the media streams in a session.
The unify draft describes the negotiation of the media components and their
corresponding codecs.
The manyfolks draft provides a way to ensure the resources (QoS & security) are
available before accepting the session, what it doesn't mention is what QoS (level)

is needed.

Therefor we submitted yesterday a new draft (draft-bos-mmusic-sdpng-qos-00.txt) for
the
MMUSIC group describing QoS extensions for SDPng.
This QoS negotiation takes place prior to the QoS provisioning (NSIS protocol) so
the SDPng QoS negotiation occurs independently of and prior to the QoS
provisioning. The SDPng QoS information can be very usefull to know the QoS level
to be requested in for example the  'NSIS protocol'.

P.S.: I suppose the draft should be available soon on the IETF directories,
otherwise people who are interested
can always send me a mail.

Regards,
    Suresh