Subject: [Sipping] Comments on Policy documents

From: "Eric Burger" <[email-masked]>
Date: Sun, 29 Feb 2004 09:04:25 -0500

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

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

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?

_______________________________________________
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