Filtering Media Attributes

Yeti-Switch
1

Hello,

I have an upstream carrier who has a=rtcp:12301 IN IP4 CARRIER_IP in the media attribute of SIP INVITE, how can SEMS filter it the SDP it stop passing-thru to the Downstream carrier? This reason being, in Leg B, We have c=IN IP4 SEMS_IP and a=rtcp:12301 IN IP4 CARRIER_IP causing some sort of IP mismatch and call being dropped at the downstream end. Hence, I was wondering, what would be the best way to tackle this issue?

2020/12/15 11:09:14.737272 CARRIER_IP:5060 -> YETO-LB_IP:5060
INVITE sip:DST_NUM@YETO-LB_IP:5060 SIP/2.0
Record-Route: <sip:CARRIER_IP;ftag=as58c6f6bc;lr;did=0b8.d3e2>
Via: SIP/2.0/UDP CARRIER_IP:5060;branch=z9hG4bKf77b.2e337cc8d8f032e4fbd3f6d3485019ae.0
Max-Forwards: 69
To: <sip:DST_NUM@CARRIER_IP:5060>
From: "SRC_NUM"<sip:SRC_NUM@CARRIER_IP>;tag=as58c6f6bc
Call-ID: 1869679a3b1650ef69bf9e584dd149f5@CARRIER_IP:5050
Contact: <sip:SRC_NUM@CARRIER_IP:5060>
CSeq: 102 INVITE
User-Agent: ZT PBX
Date: Tue, 15 Dec 2020 11:09:14 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
X-DID: DST_NUM
X-TRUNK: SIP_USER_ID
Content-Type: application/sdp
Content-Length: 555

v=0
o=root 1236936780 1236936780 IN IP4 CARRIER_IP
s=ZT
c=IN IP4 CARRIER_IP
b=CT:384
t=0 0
a=msid-semantic: WMS
m=audio 12300 RTP/AVP 0 107 101
c=IN IP4 CARRIER_IP
a=rtcp:12301 IN IP4 CARRIER_IP
a=rtpmap:0 PCMU/8000
a=rtpmap:107 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
m=video 17288 RTP/AVP 99
c=IN IP4 CARRIER_IP
a=rtcp:17289 IN IP4 CARRIER_IP
a=rtpmap:99 H264/90000
a=fmtp:99 redundant-pic-cap=0;parameter-add=0;packetization-mode=0;level-asymmetry-allowed=0
a=recvonly
2

Any update team?

3

Hi Rabani
Looking at the INVITE you shared, It doesn’t seem like the rtcp a-line is the issue. This a-line simply specify rtcp details and has nothing in common to the c-line.

What SIP Rejection Code are you getting from Downstream?
In your INVITE the upstream is also trying to initiate a receive-only video call. Have you tried disabling the video to see if the audio call goes fine?

4

@EAfang We are not able to control the Upstream INVITE from the Carrier, hence, I was looking forward to a way to filter those attributes using SEMS and send a filtered INVITE to the downstream.

and the issue with the Downstream is that in the leg b INVITE (SEM->DownStream), it has a=rtcp:12301 IN IP4 UPSTREAM_CARRIER_IP instead of a=rtcp:12301 IN IP4 SEMS_IP, therefore, it is causing a mismatch which is forcing the DownStream to drop the call

5

I am looking at the INVITE and I see you are using the Load Balancer (Kamailio) with SEMS.

If I understand your setup for call flow from upstream (vendor) to downstream (customer), it is as follows:
Vendor → LB(Kamailio) → SEMS → Customer

Is this call flow correct?
If yes, the the sample INVITE above, is it the LB → SEMS ?

LB is a proxy and would send CARRIER IP downstream. If you are using a single Yeti node, my advice is that you remove the LB as it’s not needed.

6

The issue I’m trying to solve is the leg b not leg a

Leg B is

Bypassing LB doesn’t help either as SEMS is still carrying forward the Upstream carrier IP in its media attribute which it should as SEMS should doing Topology hiding. Maybe @dmitry.s Can help us understand better as to why SEMS isn’t hiding/removing upstream Carrier IP in leg b media attributes of the INVITE (SEM → CUSTOMER):
a=rtcp:12301 IN IP4 UPSTREAM_CARRIER_IP instead of a=rtcp:12301 IN IP4 SEMS_IP