[SIPForum-techwg] IP PBX / SP Interop Draft Version 5 proposededits

[Rohan Mahy]

Hi,


On Mar 4, 2006, at 22:45, Hadriel Kaplan wrote:
> [breaking response into chunks]
>
> Hi again,
>
>> -----Original Message-----
>> From: techwg-bounces at sipforum.org 
>> [mailto:techwg-bounces at sipforum.org] On
>> Behalf Of Rohan Mahy
>>
>>> My real problem is for the last 2 conditions: "all the c= lines
>>> containing public IP Addresses" and the candidate lines one - 
>>> changing
>>> contacts and body contents will work under those conditions (safely)
>>> and does every day (well not done for ice since no one does ice).
>>
>> Would you be satisfied if the draft said a SIP intermediary (SIP proxy
>> or B2BUA) MUST NOT modify IP addresses or port numbers in the body of 
>> a
>> SIP message meeting one of these 2 last conditions?  (As opposed to 
>> the
>> entire body?)
>
> I'm not clear what the difference is from the original rules.  It 
> already
> says that, doesn't it? (sorry, I must be missing something obvious)

The language doesn't prevent you from doing codec filtering in the last 
2 cases (already provided public IP addresses or is using ICE), just 
from doing NAT "fixup" where it is not needed.

>>> Perhaps I'm reading into your phrasing too deeply, but it seemed as 
>>> if
>>> you
>>> were implying intermediaries cannot reject messages meeting the other
>>> constraints.
>>
>> No, intermediaries are allowed to reject messages for a variety of
>> reasons.  Its modifying and then forwarding that is problematic.
>
> Ahhh.  Ok, that clears up one big piece for me.

glad we are getting somewhere.

>> As for codec filtering, the whole...
>> [snipped out couple paragraphs about codec filtering being 
>> unnecessary]
>
> I don't think I ever said anything about codec filtering.(?)  Codec
> filtering is something SBCs can do, but it's fairly uncommon for 
> service
> providers to have them do it as far as I know.  It's certainly not a 
> common
> reason to use SBCs.  Unless you mean filtering the media itself?

you did mention it.

>>> If the SIP request goes to a media gateway,
>>> then PSTN to another media gateway, then SIP to the final user - are
>>> the media gateways intermediaries?
>>> What about if the PSTN was a loopback cable?
>>
>> no
>
> But that is also a B2BUA, or could be if someone were crazy enough to 
> build
> one that way.  In the SBC world (which is only a subset of b2bua's
> obviously) from outside the box, if you sniffed the wire on both 
> "sides", it
> could look exactly as if the call had gone through 2 pstn gateways.  
> Or not,
> depending on the operator's wishes and the particular SBC maker of 
> course.
> So in that case would the SBC be ok to do what the operator wishes with
> message bodies?

this discussion of what an intermediary is strikes me as pedantic and 
academic.

once you leave the IP domain, all the IP addresses in the message are 
effectively lost.  Since the whole purpose of this spec is to deliver 
calls over IP to the PSTN, I think the point is moot.

>> We are concerned with a particular SIP request from the time it leaves
>> the Enterprise until it arrives at the UAS the represents the
>> Request-URI.
>
> I assumed you also meant for requests from the service provider to the
> enterprise.  A b2bua is a uas, and in an enterprise model of service
> providers providing PSTN service, the SBC is the target of the 
> request-URI,
> at least from the perspective of the enterprise in this sip-connect 
> service.

Not necessarily.  If a B2BUA is added administratively to the Route 
set, it generally does not represent the resource at the Request URI.  
I don't care who adds it.

>> If a previous SIP element bothered to use public address in a c= line,
>> use ICE, Identity, or S/MIME, the nodes before you have indicated a
>> high degree of competency and standards awareness and are implicitly
>> agreeing to handle the NAT issues on their own.  THEY DO NOT NEED YOUR
>> HELP, thank you very much.   You cannot possibly make things better.
>> If someone sends your SBC private addresses, I do not object to you
>> modifying the message.  My language does not prevent that.
>
> You're right - the "aware" devices don't need anyone's help to get 
> media to
> them.  The problem is getting media to the far end, which may not be as
> "aware".  That cannot be solved by only changing the SDP of the 
> response.
> At least not in most cases today.

please provide a concrete example.

>>> some of them have to do with security issues,
>>
>> The whole purpose of SMIME and Identity are to provide better 
>> security.
>>   If I bothered to include SMIME or Identity in my message, you can't
>> make the security better.
>
> I didn't say which security issues SBCs address, and I'm sure you agree
> s/mime and identity are only a tiny part of the security landscape 
> (which is
> such a nebulous term to begin with).  Different SBC vendors do 
> different
> things for different reasons, and obviously I can't comment on what we 
> do in
> particular.

if you can't justify it publicly, its out of scope.  we have no 
responsibility to work around vaguely asserted secret requirements 
here.

> I will just say that you're really arguing with the wrong guy about 
> some of
> this.  If service providers didn't want something done, we wouldn't do 
> it
> (if it were technically possible).  If we stopped doing something 
> because
> the IETF didn't like it, we'd just be replaced with a different vendor 
> that
> did what the service provider wanted.  I'm sure the same is true of
> enterprise firewall and SBC vendors.

what requirement?

thanks,
-rohan

>> I do not object to a B2BUA responding with a 493
>> Undecipherable if it cannot read an SMIME *encrypted* message that it
>> is legally required to read. My proposed language does not prevent
>> that.
>
> OK, cool - that was one of the parts I didn't understand.  Perhaps the
> wording should include that, if it gets accepted.
>
> -hadriel
>