Subject: Re: [Sipping] Comments on Policy documents

From: Volker Hilt <[email-masked]>
Date: Mon, 01 Mar 2004 17:22:30 +0900

Eric,

thanks for the comments. Responses are inline.
> On sipping-spec-policy-00 -
> 
> Do we really need end-to-end, two-party acceptance of proxy policies?
> 
> Motivation: to the UAC, there is no difference between a proxy saying
> "you can only do G.711" and the UAS returning an answer saying
> "please only use G.711".
> 
> Conversely, to the UAS, there is no difference between a proxy saying
> "please only do G.711" and the UAC offering only G.711.
> 
I think it is important that at least *one* UA agrees to using a certain 
policy. It seems to be sufficient to have agreement from one UA since 
that UA could have generated the "policy-modified" SDP announcement on 
its own, i.e. without the impact of policies. In the above example, the 
UAS (or UAC) could have decided to on its own to just use G.711. Btw. 
this is the consent model that is used in OPES for intermediaries.

The advantage of the "one-party consent model" is that it simplifies 
call flows. Furthermore, in some cases providers do not want to expose 
their policies to entities outside their network. In this scenario, it 
is even desirable that only the local user agent knows about (and agrees 
to) policies.

> I *can* see letting the UAC know what is going on from a human
> factors perspective.  Let's say I bought the latest foobratz phone
> that does quadraphonic-better-than-CD-quality audio.  However, I can
> never use it, because everyone comes back answering with G.729ab.  It
> might be nice to know that it is because a proxy limited me, not that
> my fancy phone doesn't work.  As the owner of the UAC, I have
> expectations of the fancy stuff working.  That said, if my fancy
> phone is in the UAS role, I have expectations that other people
> *don't* have my fancy features, especially if my INVITES only have
> G.711 in them.
> 
Even if the fancy phone is on the UAC side, the 
quadraphonic-better-than-CD-quality audio would only work if it is 
supported by the UAS. If the UAS accepts the policy to use G.729ab its 
the same situation as if the UAS would be a simple device that does not 
support quadraphonic audio. If the user with the fancy phone is on the 
UAS side, it would see the policy.

Btw. the redirect model discussed in SIPPING today has the interesting 
characteristic that policies are accepted by user creating the 
respective SDP announcement. I.e. the UAC would see the policies that 
apply to the SDP offer and the UAS the policies that apply to the answer 
(and not vice versa as in the piggyback model).

> In another issue, consider section 3.1.2.  The document states that
> it is not recommended for a proxy to reject a request that doesn't
> honor the MFO.   It may be better to state the obvious alternative: If
> the proxy really has to enforce the policy, it flips into B2BUA mode.
> By definition, end-to-end is broken (from the carrier's perspective),
> so the carrier will jump in and "fix it".  The idea being that if
> everyone plays by the rules (or suggestions), one won't have to look
> for another service provider that doesn't feel like billing :-)
> 
I'm hesitating to put in a B2BUA as the fall back solution. Depending on 
the nature of the policy, a provider may decide to allow the call to be 
completed without policies, reject the call, use a 488 response, or a 
B2BUA to fix this problem. The current draft allows all of these 
solutions and suggests that a Requires header is inserted into the 
request.

> I would also suggest stating that proxies MUST NOT mix its MFO's on a
> media-filter header populated with MFO's from another proxy.  That
> is, a proxy can add media-filter headers, but it cannot modify
> existing ones.  This is supported already in the syntax.  However, I
> would make this a MUST to make it easier to sign headers and ensure
> they don't break header signing.
> 
I fully agree with this. I think MFO's should only depend on the MIO and 
never try to analyze what previous proxies have requested.

> Lastly, is there any reason to use different formats for
> session-specific versus session-independent policy (headers v. XML)?
> XML is more expressive -- if we wanted to keep XML, how about using
> cid:'s for the session-specific MFO statements?
> 
Yes, having the same format for both, session-independent and 
session-specific policies would definitely simplify things. Allowing the 
proxy to insert bodies would probably solve this problem for the 
piggyback model. In the redirect model, the session-independent 
mechanism would be re-used directly.

Thanks,

Volker

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP