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

[Rohan Mahy]

Hello again,

On Mar 4, 2006, at 23:42, Hadriel Kaplan wrote:
> [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.

The current version of the spec already requires public IP addresses on 
each side.

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

Can you publicly provide an in-scope example that breaks with public IP 
addresses?

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

My revised proposal would not allow the SBC to modify the IP address or 
port number (unless SMIME or Identity is in use).

thanks,
-rohan