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

[Hadriel Kaplan]

Hi,
Sorry for not responding sooner, got sidetracked...

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan at ekabal.com]
> >> 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.

Ahh, I see - I actually had already assumed that of your original rule set,
namely that it only restricted an intermediary from modifying the IP address
or port in the body or contact in such cases.  

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

Sorry, as I said in my previous email after this one I thought you meant the
SBC provides its own address, not the endpoint's NAT's public address.
Again, this is off-scope, but if an SBC provides the NAT's address it will
work most of the time, just not 100% of the time.  

One of the reasons for that, for even the simple NAT traversal case I was
describing is the UDP port(s).  In most cases it/they will be the same one
as in the SDP, but not every time - so the ice endpoint won't be sending
media to the right port to get through the far-end NAT to get to the non-ice
peer.  The TURN server will not send media back to the far-end at a
different port either (unless I read the draft wrong).  It's also one of
those bizarre problems that happens now and then but not every time, even on
the same NAT (I think someone pointed out on mmusic already a long time ago
that some NATs change their behavior based on the port number, their cache
usage, or even firmware rev).  It's certainly not a big deal for someone
trying to get cheap phone, but it's ugly for a service provider to have
1-way media even 1 in 10,000 times. (they'd prefer a busy signal to that I
think) 

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

I totally agree with you, and I apologize for it and believe me I wouldn't
have expected such.  As I said a bit ago on this list normally I would not
even have commented on a requirement such as your's being in the spec,
because those that did not wish to or could not follow it simply wouldn't -
there is no service of this spec that needs an SBC to follow these 4 rules.
My only concern was that it implied services would be supported which were
not in the spec (because I thought your phrasing meant SBCs could not reject
such messages, for example), and that I was concerned about interop given
that many service providers would not be able to follow this ruleset.

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

To inspect signaling, be able to modify it, to control media, to be able to
modify it, to accept/reject/throttle requests, etc., etc.  Those are the
things it must do to be able to support the specific functions many service
providers want.  I know you can't accept such requirements because they may
prevent some current or future IETF mechanism, and I'm not asking you to - I
was just asking for the spec not to mandate the opposite.  I was trying to
keep a specific service specification defining interop procedures between
two independent entities (as opposed to the public internet at large) from
going beyond its scope, and from creating rules which cannot be met by a
large sector of those entities which may lead to interop problems down the
road.  But I think we'll just have to deal with it when it comes.  In the
scope of this sip-connect doc's services I don't think breaking compliance
with your ruleset would create issues.

-hadriel