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

[Hadriel Kaplan]

[breaking the response up into chunks]

Hi again,

> -----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
> Behalf Of Rohan Mahy
> 
> > They will also cause interop problems in the sense that were an
> > intermediary
> > to follow the rule and not modify in those conditions, the service
> > will fail
> > in some cases.  For example, if a request from a sip-connect compliant
> > enterprise has candidate lines, and gets forwarded through the service
> > provider to a home user who's NAT traversal is being fixed by the
> > service
> > provider's SBC, then if the SBC does not change the SDP IP info (which
> > was
> > public and correct and has candidate lines), the call will fail almost
> > every
> > time.
> 
> This is an excellent example.  Fortunately your analysis is incorrect.
> The SDP provided by peer A has ICE candidate lines.  The SDP provided
> by peer B does not.  An SBC following my proposed rules would modify
> the SDP provided by peer B to have public IP addresses and would leave
> SDP A alone.  A working audio path would follow.

This scenario is probably off-topic for this sip-connect draft (oh well).  I
re-read your paragraph a few times to try to understand why you think it
will work, and I think I know now why you think so.  You're thinking the SBC
would provide Peer B's NAT's public IP address in the response?  It's
actually not the way I first thought you were trying to let it work, but
it's interesting.  Not many service providers let us do that though, even
when we want to for other reasons.

But even if they did, I'm sticking with no it won't, not every time.  It is
probably no secret how most SBCs fix NAT traversal in general, but I can't
divulge how ours does.  All I can say is not changing the request SDP will
not work consistently, and it won't work for a majority of other SBC vendors
either.  Not given the current ice/stun/turn drafts, and not given how
different NATs and non-ice UAs around the world work, and not given how
different service providers we've seen design their networks.  It will work
in some cases, and some not.  Our problem is it has to be 100%, or the
service provider gets very unhappy.  :)


> If the SBC modified candidate lines, its quite likely that the call
> would fail.  If you'd like I can probably dig up a trace of such a
> case.

But I wasn't suggesting the SBC would modify the candidate lines.  Your rule
wouldn't allow the SBC to modify any lines with ip/port in them, I think.

-hadriel