[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Re: Manyfolks Clarifications
Hello,
Alan O'Neill wrote:
> The above discussion therefore suggests to me that all preconditions must be
> assumed to be end to end, that the e2e tag for the QoS mechanism is useless
> because it can never be safely applied, and therefore that the e2e tag be
> removed.
Look at the DCS architecture. They can besure when they have e2e QoS
resources. And in my intranet, when my QoS reservation protocol tells me
that I have e2e QoS service, it is because I have it.
If you think that having e2e QoS is impossible, you should provide
feedback to a different WG. Not SIP.
> The local/remote model is on the right path but I believe incomplete.
> Essentially, the model should be that the MN has an SLA wrt QoS with some
> limited scope (on-net, offnet to specific prefixes etc). The caller seeking
> preconditions simply adds in the Invite that that is the case, and will
> clearly only do so if believes it has a candidate SLA at its end.
Look at the 3GPP architecture. They have enough resources in the
backbone. The only thing that worries them is the radio interface. With
the local and remote tags they perform PDP context activation... it
works.
>but the UAs should still be able to reduce
> their preconditions to attempt a best effort call in these circumstances if
> they so desire.
This is always possible.
> A related issue that I would like to raise is that given that the actual IP
> prefix of the callee is not known at the time of the offer (and hence the
> caller neither actually knows if it does have an SLA or a QoS mech for that
> callee prefix), it is critical that the preconditons be able to be flexibly
> adjusted in response to additional information.
That's why you have the carry the current status in the SDP. Because
once you receive the first answer you can update it (because you know
the destination IP address)... and if you required e2e QoS and after
getting the remote IP address you notice that it is impossible, you do
not want to establish the session, because your requirement cannot be
fulfilled. If you want, you can send a new offer without preconditions,
but the first offer/asnwer fails correctly, because your preconditions
could not be met.
> I would therefore suggest
> that preconditions should be able to be increased or decreased at either
> end, and not just increased.
You can always send new offers. The only place where you can only
upgrade the strength tag is within a single offer/answer exchange.
Thanks for your comments,
Gonzalo
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip