Christian Jansson wrote:
> Oops, I am sorry. I just saw that Paul have actually given me an answer.
>
> Comments below.
>
>
>>Christian Jansson wrote:
>>
>>>>Paul Kyzivat wrote:
>>>>
>>>>- a dialog stateful proxy will maintain dialog state, which consists
>>>> primarily of callid, cseq, local and remote targets (contacts),
>>>> and route set.
>>>
>>>
>>>What is the reason a proxy would want this information given that a
>>>proxy can't send requests?
>>
>>Good question!
>>
>>Maybe so that it can claim to be a proxy most of the time and just
>>"break the law" now and then. (E.g. to send a BYE.)
>>
>>(Note that I am not advocating this.)
>>
>>I guess it could also be useful to *verify* that certain policies are
>>being followed.
>
>
> "Could be used ... certain polices...", hmmm ... no real hard fact use
> case there. To me it seems that we could state that "There is no need
> for a dialog stateful proxy, as it can't use the dialog information for
> anything useful", perhaps together with "Anything that is not a SIP
> proxy (B2BUA, SBC, you name it) can do anything it likes except calling
> itself a SIP proxy"
Well, an IMS example of this policy enforcement is: verify that
in-dialog requests contain route headers consistent with the route-set
for the dialog.
The same proxy is also "registration stateful" so that it can: verify
that out-of-dialog requests are consistent with the Service-Route
returned during registration.
Both of these are policy enforcement actions on the signaling path. Some
operators are anal about this sort of thing and want to be restrictive
like this.
Note that *this* sort of behavior is consistent with being a proxy.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
