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

[Hadriel Kaplan]

[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)

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

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

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


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


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


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

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.


> 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