[Spce-user] Remove local address from Peer INVITE Record-Route / Via Headers

[Daniel Grotti]

Hi,
unfortunately that's not possible, you will break the entire call flow.
If it still does not work with the workaround, then you should put in 
front a B2BUA/SBC in order to send the INVITE out just with 1 RR.



--
Daniel Grotti


On 02/20/2017 07:50 AM, Nathaniel Pitcher wrote:
> Thanks again for the reply.
>
> Would there be any functional problem with putting everything on the
> same public interface instead of using an internal address?
>
> Obviously this poses some potential security issues, but I am already
> blocking everyone except trusted IPs using iptables.
>
> At this point making calls complete without hanging up mid call is more
> important.
>
> Nathaniel Pitcher
>
> -----
> Sent from my mobile device. Please forgive any errors.
>
> On Feb 18, 2017, at 9:56 AM, Daniel Grotti <dgrotti at sipwise.com
> <mailto:dgrotti at sipwise.com>> wrote:
>
>> Currently is not possible.
>> We are working to include a topology hiding, in order to pursue this
>> scope. But still not available, sorry.
>> Another possibility is to put a B2BUA on front of ngpc, that creates a
>> new leg with only 1 RR and 1 via header.
>>
>> Daniel
>>
>> On Feb 18, 2017 5:17 PM, Nathaniel Pitcher <nathaniel at inmtn.net
>> <mailto:nathaniel at inmtn.net>> wrote:
>>
>>     Daniel,
>>
>>     Thanks for the reply. I actually tried that already. As you can
>>     see in the invite I included the local address is now a 10.
>>     network instead of 127.
>>
>>     We still have the same issue where we receive the early media RTP
>>     and are then disconnected about 30s in.
>>
>>     So there is no way to make the invite to the peer appear to
>>     originate from the public ip?
>>
>>     I can see how having an internal address could be confusing once
>>     it is routed to another network as it would not be able to route
>>     back.
>>
>>     Nathaniel Pitcher
>>
>>     -----
>>     Sent from my mobile device. Please forgive any errors.
>>
>>     On Feb 18, 2017, at 4:19 AM, Daniel Grotti <dgrotti at sipwise.com
>>     <mailto:dgrotti at sipwise.com>> wrote:
>>
>>         Hi,
>>         That's not possible, what you can do is to use a dummy
>>         interface and IP, instead of localhost.
>>         Please have a look at:
>>         https://www.sipwise.org/doc/mr4.5.3/spce/ar01s04.html#_audiocodes_devices_workaround
>>
>>
>>         Daniel
>>
>>
>>         On Feb 18, 2017 3:58 AM, Nathaniel Pitcher
>>         <nathaniel at inmtn.net <mailto:nathaniel at inmtn.net>> wrote:
>>
>>             We are having a problem with some calls going to a peer.
>>
>>             We make a call and receive early media and then after
>>             about 30s the call is terminated.
>>
>>             In speaking with our provider and giving them some pcaps,
>>             they seem to think that their upstream provider does not
>>             like seeing “local” IPs in the Record-Route or Via SIP
>>             headers.
>>
>>             Is there a way that we can only show the public IP when we
>>             send the invite to a peer?
>>
>>
>>
>>
>>
>>             Below is the invite:
>>
>>
>>             2017/02/18 01:48:59.218055 xxx.197.197.130:5060 ->
>>             xxx.115.69.144:5060
>>             INVITE sip:12223334444 at xxx.115.69.144:5060;transport=udp
>>             SIP/2.0
>>             Record-Route:
>>             <sip:xxx.197.197.130;r2=on;lr=on;ftag=1DBB886B-58A7A80B0003501E-C6CEC700;ngcplb=yes>
>>             Record-Route:
>>             <sip:10.111.111.111;r2=on;lr=on;ftag=1DBB886B-58A7A80B0003501E-C6CEC700;ngcplb=yes>
>>             Via: SIP/2.0/UDP
>>             xxx.197.197.130;branch=z9hG4bK1dde.7f15d8fccb769b263f65fef36ad1e9be.0
>>             Via: SIP/2.0/UDP
>>             10.111.111.111:5080;received=10.111.111.111;branch=z9hG4bK6ldVKae7;rport=5080
>>             From:
>>             <sip:19518948809 at sip.server.net>;tag=1DBB886B-58A7A80B0003501E-C6CEC700
>>             To: <sip:12075552*17608021325 at xxx.115.69.144>
>>             CSeq: 10 INVITE
>>             Call-ID: 8b3190a6-3707-4bee-9322-97b7a4e31430_b2b-1
>>             Max-Forwards: 69
>>             Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK,
>>             BYE, CANCEL, UPDATE, PRACK, MESSAGE, REGISTER
>>             Supported: 100rel, replaces, norefersub
>>             P-Asserted-Identity: <sip:15554443333 at sip.server.net>
>>             Content-Type: application/sdp
>>             Content-Length: 276
>>             Contact:
>>             <sip:ngcp-lb at xxx.197.197.130:5060;ngcpct=7369703a31302e3133382e302e3130353a35303830>
>>
>>             v=0
>>             o=- 899528559 899528559 IN IP4 172.16.123.123
>>             s=Asterisk
>>             c=IN IP4 xxx.9.52.19
>>             t=0 0
>>             m=audio 11590 RTP/AVP 0 8 101
>>             a=rtpmap:0 PCMU/8000
>>             a=rtpmap:8 PCMA/8000
>>             a=rtpmap:101 telephone-event/8000
>>             a=fmtp:101 0-16
>>             a=sendrecv
>>             a=ptime:20
>>             a=maxptime:150
>>             a=direction:both
>>
>>
>>
>>
>>
>>