Reply to JBaclor: "[ sipXbridge 17.04 ] Trunk group (dial plan)..."

[cmasc...@gmail.com]

Posting in a new thread because all of my posts to the original thread are getting deleted. ???

If by 'calling UA' you mean the endpoint placing the call, it's a Polycom SoundPoint IP 450, firmware 4.0.12.
I just tried the same thing with a different endpoint: CSipSimple 1.02.03 r2469: inbound media OK!
I repeated the test with the Polycom: no inbound media.
All endpoints and sipXcom are on the same LAN.
SIP signalling does have early media (183 response).

I must be missing something, because the SIP signalling between sipXcom and the endpoint looks the same to me for the 1-trunk case (no trunk failover) and the 2-trunk case. I don't see how the endpoint knows the difference between the two cases, so I don't understand why the Polycom works in the 1-trunk case but not in the 2-trunk case.

What is a forked early media stream?

[Joegen Baclor]

CSIPSimple working and not the Polycom pretty much confirms that this is a UA issue.   Forked early media is basically two or more 183 (with SDP) coming from different endpoints.  They convey two or more distinct streams.  Polycom is known to work well with forks but I am not really sure if there is a known issue with forked calls with multiple early media.   Perhaps a firmware upgrade is in order and see if things improve.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/f3d71a79-251d-4db8-8b39-ebc1d0cc6369%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[cmasc...@gmail.com]

There are only two SDP bodies from sipxbridge in the SIP signalling between sipXcom and the endpoint:

- 183 Session progress
- 200 OK

The two are identical:

        v=0
        o=sipxbridge 3732412437316930536 1 IN IP4 192.168.1.22
        s=ENSResip
        c=IN IP4 192.168.1.22
        t=0 0
        m=audio 30506 RTP/AVP 0
        a=rtpmap:0 PCMU/8000
        a=maxptime:20

So there's no forked early media.

I updated the Polycom's firmware to 4.0.13 (latest): same problem.
It certainly has something to do with the endpoint, since CSipSimple works OK, but I'm not quite sure where to point the finger.
Now I'm stumped.

On Tuesday, March 13, 2018 at 11:41:11 AM UTC-4, JBaclor wrote:

CSIPSimple working and not the Polycom pretty much confirms that this is a UA issue.   Forked early media is basically two or more 183 (with SDP) coming from different endpoints.  They convey two or more distinct streams.  Polycom is known to work well with forks but I am not really sure if there is a known issue with forked calls with multiple early media.   Perhaps a firmware upgrade is in order and see if things improve.

On Tue, Mar 13, 2018 at 10:14 PM, <cmasc...@gmail.com> wrote:

Posting in a new thread because all of my posts to the original thread are getting deleted. ???

If by 'calling UA' you mean the endpoint placing the call, it's a Polycom SoundPoint IP 450, firmware 4.0.12.
I just tried the same thing with a different endpoint: CSipSimple 1.02.03 r2469: inbound media OK!
I repeated the test with the Polycom: no inbound media.
All endpoints and sipXcom are on the same LAN.
SIP signalling does have early media (183 response).

I must be missing something, because the SIP signalling between sipXcom and the endpoint looks the same to me for the 1-trunk case (no trunk failover) and the 2-trunk case. I don't see how the endpoint knows the difference between the two cases, so I don't understand why the Polycom works in the 1-trunk case but not in the 2-trunk case.

What is a forked early media stream?

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.

[cmasc...@gmail.com]

The SDP bodies (again 2 identical) in the 1-trunk case (using trunk 2, the trunk that completes the call in the failover case) are slightly different:

        v=0
        o=sipxbridge 8320022921355809666 1 IN IP4 192.168.1.22

        s=ENSResip
        c=IN IP4 192.168.1.22
        t=0 0

        m=audio 30502 RTP/AVP 0

        a=rtpmap:0 PCMU/8000
        a=maxptime:20

The differences are the port # and the addition of 'a=maxptime:20'.

[cmasc...@gmail.com]

I think I have found the problem and a workaround.

On sipxbridge external side:

SDP port negotiated by sipxbridge:

trunk 1 (failing):        30502
trunk 2 (completed): 30506

On sipxbridge internal side:

SDP port negotiated by sipxbridge: 30506

Packet capture on LAN shows RTP packets from sipXcom to Polycom or CSipSimple being sent from both 30502 and 30506.
I believe this is a sipxbridge bug: sipxbridge should be sending to Polycom only on 30506 (negotiated). 30502 was the external RTP port negotiated by sipxbridge for trunk 1 only, but no call was ever completed on trunk 1, nor did trunk 1 ever get as far as sending/receiving any media, including early media.

The Polycom workaround: change tcpIpApp.port.rtp.filterByPort from 0 (default) to 1.
Result: Inbound media OK on Polycom using trunk 2 after failover from trunk 1. Polycom media statistics after end of call: Lost Packets: 0.

Why did it work with CSipSimple? Apparently because by default, unlike Polycom, CSipSimple ignores RTP from any port but the negotiated port.

On Tuesday, March 13, 2018 at 10:14:03 AM UTC-4, cmasc...@gmail.com wrote:

[Joegen Baclor]

Not a bug in sipXBridge.   This is simply how forked calls with early media works.   A UA must be prepared to receive from multiple streams when a call is forked.  It then chooses whether to drop , render or even mix the streams.   I am glad you found the workaround.   Perhaps sipXcom needs to have that as the default for polycom templates.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/a85065cd-b803-4ebc-8d5b-6c177c3921c0%40googlegroups.com.

[cmasc...@gmail.com]

While a UA must be prepared to receive from multiple streams, in this case there is only one real stream: the one coming from sipxbridge port 30506. The stream coming from sipxbridge port 30502 is a phantom stream, probably a partial or full duplicate of the real stream (because there's no other media coming in to the external side of sipxbridge). Remember, rejecting the stream from 30502 leaves the Polycom with a complete stream, no missing packets.

In other words, sipxbridge is manufacturing a phantom stream on 30502. sipxbridge should have killed, removed, whatever port 30502 once the call on trunk 1 failed (without ever exchanging media). Again, 30502 was sipxbridge's external media port for trunk 1. I think that's a bug in sipxbridge.

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

[Joegen Baclor]

sipXbridge, or should I say sipXmediarelay is a plain RTP proxy.  It won't, (in fact it can't) generate bogus RTP traffic.   So whatever you are seeing came from somewhere (most likely the first trunk).    There might indeed be a bug but without actual pcaps to look at I can't really tell if this is a sipXbridge issue or not.

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/3fe568cb-b4cb-47c5-81a9-bdcad35ea76f%40googlegroups.com.

[Joegen Baclor]

It's easy to tell if you are getting duplicate streams sent from differnt ports.  The stream should have the same SSRC.    If this is a case, then it's a bug.  However, if it is a duplicate, the UA receiving duplicate packets should simply drop the packet with the same sequence number as the one it previously processed.  PCAP can save us a lot of assumptions.  If it reveals sensitive  topology information, feel free to send me a copy off list.

[cmasc...@gmail.com]

Here's a link to a sanitized WAN SIP trace and a LAN pcap.
The WAN and LAN sides were captured on two different calls, so the RTP port #'s aren't the same. The pattern is the same, however: trunk 1 = port n, trunk 2 = port n+4.

The WAN trace shows that no media was ever negotiated for trunk 1.
The LAN trace shows the same SSRC and duplicate sequence #'s for source ports n+4 and n.
Also note the weird change at the end of the call: output from port n+4 stops, sequence # and SSRC change.

https://www.dropbox.com/s/ngy2xomkinoyh0e/sipX_failover_WAN_LAN.zip?dl=0

[Joegen Baclor]

Yeah this is a bug in sipXbridge.   It should have closed the media channel on receipt of the error response from flowroute.  However, flowroute seems to be continously streaming after it has sent out the error response.  This is understandable since PSTN gateways normally convey channel congestion using actual audio.   It's been a while since I last touched the sipXbridge code.   If it's an easy fix, I might send in a patch to the eZuce folks if they don't beat me to it.   Would you mind sending sipXbridge logs in debug?

To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-users+unsubscribe@googlegroups.com.

To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/00835bde-66f6-4745-9f42-a882ab18660d%40googlegroups.com.

[cmasc...@gmail.com]

I didn't follow what you said about PSTN gateways and channel congestion. The mystery 3rd stream is on the "flowroute" port, and the call was rejected by flowroute immediately, so flowroute never reached a PSTN gateway and thus there was no possibility of channel congestion. Again, there was never a media negotiation between sipXcom and flowroute: sipXcom sent an INVITE, there was no 183 or 200 response. Flowroute rejected the call because I had intentionally set my max per-minute rate to $0.00 to cause the rejection (for testing).

Anyway, this is sort of a going off on a tangent -- if sipxbridge had closed the flowroute port the mystery stream wouldn't be there.

Here's a link to the sipxbridge debug log. See the Readme.txt file for where to look in the log for the start of the test call.

NOTE: 17.04 is not the latest sipxbridge: in 17.10 DNS SRV lookup of proxies was added (UC-4518). There are no other documented (release notes) changes.

It's really nice of you to take a look at sipxbridge, but if I were you I'd make sure that eZuce would apply any patch you gave them before I invested too much time in it. eZuce seems to be tied up with Swarm now and sipXcom doesn't seem to be getting much of eZuce's attention. I filed a Jira (SIPX-703) on this on 11/23/17 -- it is still unassigned.

https://www.dropbox.com/s/ipsjfn9gkzzdyn7/sipxbridge.zip?dl=0

[cmasc...@gmail.com]

New link for sipxbridge debug log.
I neglected to sanitize the previous log. :-(

https://www.dropbox.com/s/zrb0dy6rxdy7qu4/sipxbridge.zip?dl=0

[Matt Keys]

I pinged eZuce contacts in the JIRA ( http://jira.sipxcom.org/browse/SIPX-703 ).

Regards,

Matt

On Thursday, March 15, 2018 at 9:20:40 AM UTC-4, JBaclor wrote: