[Spce-user] Rtp source address changes after in-dialog Invite

[Chris Hoffmann]

Hi Walter,

Thanks for your reply.

For reference here is my network.yml. I have my client subscriber
configured with 'rtp_interface' as 'ext'. I am unsure how to set a default
RTP interface?

hosts:
  self:
    dbnode: '1'
    ens192:
      ip: 192.168.x.x       | INT-ETH
      netmask: 255.255.255.0
      type:
      - ssh_ext
      - web_int
      - web_ext
      - rtp_int_ens192
      - sip_ext_incoming
    ens224:
      dns_nameservers:
      - 8.8.8.8
      gateway: xxx.242.37.xxx
      hwaddr: xx:xx:29:23:xx:xx
      ip: xxx.242.37.xxx      | EXT-ETH
      netmask: 255.255.255.240
      type:
      - web_ext
      - sip_ext
      - rtp_ext
    interfaces:
    - lo
    - ens224
    - ens192
    lo:
      cluster_sets:
      - default
      ip: 127.0.0.1
      netmask: 255.255.255.0
      shared_ip: []
      shared_v6ip: []
      type:
      - sip_int
      - ha_int
      - aux_ext
      - api_int
      - rtp_int
      - stor_int
      v6ip: ::1
      v6netmask: 128
    role:
    - proxy
    - lb
    - mgmt

Thanks for your time,

Chris

On Tue, Aug 25, 2020 at 9:21 PM Walter Klomp <walter at myrepublic.net> wrote:

> From the top of my head you can tell Sipwise to use the ext-eth port as
> the default or you can specify it in the subscriber preferences. (In case
> you have different interfaces for different clients)
>
> On Tue, 25 Aug 2020 at 15:57, Chris Hoffmann <chris021 at gmail.com> wrote:
>
>> Hi,
>>
>> I have a small bit to add to this. I reviewed a number of other calls
>> today that have been successful with in dialogue invites. It appears this
>> issue happens when the client does re-invite but the invite does NOT
>> include SDP. If the re-invite contains SDP the issue doesn't happen.
>>
>> Happy to supply captures, logs, configs etc if anyone has any ideas.
>>
>> Thanks,
>>
>> Chris
>>
>> On Mon, Aug 24, 2020 at 9:27 PM Chris Hoffmann <chris021 at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have a bit of an odd issue that I am struggling with on my sipwise box
>>> running mr6.5.2
>>>
>>> i have 2 interfaces so my setup looks like this:
>>>
>>> [Upstream Carrier] -------- [int-eth | SIPWISE | ext-eth] ---------- [My
>>> client]
>>>
>>> 99% of all calls work fine however, I have a client with a Mitel system,
>>> and when I send them a call which hits an auto attendant they send me
>>> another invite. When this happens Sipwise stops sending RTP with the
>>> ext-eth IP as the source and starts sending RTP with the int-eth IP as the
>>> source. At the same time Sipwise also sends a SIP/SDP 200 OK with the SDP
>>> packet showing:
>>>
>>> Owner/Creator, Session Id (o): root 1724471111 1724471112 IN IP4
>>> 192.168.x.x
>>> this is also the int-eth IP.
>>>
>>> Any ideas on what is going on here?
>>>
>>> Thanks,
>>>
>>> Chris.
>>>
>>>
>>
>>>
>>>
>>
>> --
>>
>> Spce-user mailing list
>>
>> Spce-user at lists.sipwise.com
>>
>> http://lists.sipwise.com/mailman/listinfo/spce-user_lists.sipwise.com
>>
>> --
>
> Warmest Regards,
>
> <https://myrepublic.com.sg/>
> *Walter Klomp*
> Head of Voice & Systems
> MyRepublic Limited
> T: +65 6816 1120
> F: +65 6717 2031
>
> MyRepublic Limited
> 11 Lorong 3 Toa Payoh Block B Jackson Square
> #04-11/15 Singapore 319579
>
> myrepublic.com.sg
> Follow us on: Twitter <https://twitter.com/myrepublic> | Facebook
> <https://facebook.com/myrepublicsg> | LinkedIn
> <https://www.linkedin.com/company/myrepublic>
>
>
>
> The contents of this email and any attachments are confidential and may
> also be privileged. You must not disseminate the contents of this email and
> any attachments without permission of the sender. If you have received this
> email by mistake, please delete all copies and inform the sender
> immediately. You may refer to our company's Privacy Policy here
> <https://myrepublic.net/sg/legal/terms-of-use-policies/privacy-policy/>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20200826/cfce18a2/attachment-0002.html>