[Spce-user] ngcpct='sip:127.0.0.1:5080' in Contact header

[Skyler]

Ah good to know, I haven't seen that be a problem 'yet' (knock wood). 
I'll step away :)

Skyler

On 3/27/2013 9:03 AM, John Murray wrote:
> Yes one problem with some vendors is the loopback address of 127.0.0.1 which
> as you say can be fixed by changing the internal address as described in
> handbook section 5.5.1.
> The other problem some vendors have is with the 'ngcpct=' section of the
> Contact: header as:
>
> Contact: <sip:ngcp-lb at 10.23.11.18:5060;ngcpct='sip:10.23.11.18:5080'>'
>
> Some vendors 'forget' this and reply to sip:ngcp-lb at 10.23.11.18:5060 and
> some get stuck and don't reply at all when they see this.
>
> Regards
>
> John
>
> -----Original Message-----
> From: Skyler [mailto:skchopperguy at gmail.com]
> Sent: 27 March 2013 15:55
> To: Andreas Granig
> Cc: John Murray; spce-user at lists.sipwise.com
> Subject: Re: [Spce-user] ngcpct='sip:127.0.0.1:5080' in Contact header
>
> Hi,
>
> On 3/27/2013 8:41 AM, Andreas Granig wrote:
>> Hi,
>>
>> On 03/27/2013 04:11 PM, John Murray wrote:
>>> With a peer you are typically in some sort of relationship and can
>>> negotiate any fixes (not always the case of course). But with a
>>> subscriber you are dependent on the code in the device.
>>> In my experience with PBXs ( naming no names (but NEC is terrible))
>>> are very bad with this header so it would be very helpful if there
>>> were some switch against the subscriber to remove this as a
>>> workaround.
>>> Getting the vendor to do something about this has always proven very
>>> difficult/painful/slow.
>>
>> Well, the reason this has been added was to mask the local sems
>> contact of 127.0.0.1:5080, because some peers are doing far-end nat
>> traversal (like the SPCE itself), and if some peer tries to fix this,
>> the SIP flow is again broken.
>>
>> So in one way or another, this information needs to be coded into the
>> message. I'm open for any better suggestions of course :)
>>
>> Andreas
>>
>
>    I created an lo:0 with a private IP address (10.10.xxx.xxx) for lb >
> b2buas: & proxies > sip:. That may help in this case as its likely the
> 127.0.0.1 which is confusing the upstream proxy.
>
> Skyler
>