How do I ensure that BYE messages bypass a SIP proxy?

Question

I am trying to build a stateless SIP proxy similar to the one in this diagram:

It behaves as it should when "Alice" hangs up first, the BYE message goes directly to "Bob" and does not touch the proxy. However, when "Bob" hangs up first, the BYE message gets lost in the ether, or reaches the proxy, not "Alice".

This is the 200 message the Proxy sends to Alice, right before the ACK (forwarded from Bob)

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.168.103:58922;received=98.0.xxx.xxx;rport=39612;branch=z9hG4bKPjkdKDifFk6647hFrB-.WRwaWW0HixPPnG
Record-Route:  <sip:208.xx.xx.11;ftag=I9jUO6GotuK.DLbMUK9.HRKStDfVA18r;lr=on>,  <sip:199.x.xxx.101;lr;ftag=I9jUO6GotuK.DLbMUK9.HRKStDfVA18r;nc=1;did=615.7e25f325;pr=3>
From: "Alice" <sip:alice@foo.com>;tag=I9jUO6GotuK.DLbMUK9.HRKStDfVA18r
To:  <sip:proxy@proxy-uri.com>;tag=as13aaa2d9
Call-ID: gL7sgrTlu7wCcQCeOqhgOSe6tr.LDu9v
CSeq: 19813 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Contact:  <sip:12340@208.xx.xx.12:5090>
Content-Type: application/sdp
Content-Length: 300

v=0
o=root 3520 3520 IN IP4 199.x.xxx.73
s=session
c=IN IP4 199.x.xxx.73
t=0 0
m=audio 59316 RTP/AVP 0 8 9 101
a=silenceSupp:off - - - -
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendrecv
a=rtcp:59317
a=ptime:20

And this is the ACK that Alice sends to Bob:

ACK sip:12340@208.xx.xx.12:5090 SIP/2.0
Via: SIP/2.0/UDP 192.168.168.103:58922;rport;branch=z9hG4bKPjKxiikjcMSTNLKavscYpxTToZfOn7AlCI
Max-Forwards: 70
From: "Alice" <sip:alice@foo.com>;tag=I9jUO6GotuK.DLbMUK9.HRKStDfVA18r
To: <sip:proxy@proxy-uri.com>;tag=as13aaa2d9
Call-ID: gL7sgrTlu7wCcQCeOqhgOSe6tr.LDu9v
CSeq: 19813 ACK
Route: <sip:199.x.xxx.101;lr;ftag=I9jUO6GotuK.DLbMUK9.HRKStDfVA18r;nc=1;did=615.7e25f325;pr=3>
Route: <sip:208.xx.xx.11;lr;ftag=I9jUO6GotuK.DLbMUK9.HRKStDfVA18r>
User-Agent: Blink Lite 4.6.0 (MacOSX)
Content-Length:  0

I only have control over the messages generated by the Proxy. I'm guessing there something I need to add / remove / change about the 200 sent by the Proxy before the ACK, but I'm not sure? Thanks in advance.

HI Adam, I know that SIP stuff is ... From the two messages, I cannot tell why Bob subsequent BYE is lost. But here is two proxies involved which one do you have control, Asterisk? A piece of advice, I suspect that there is a NAT issue. — tomrtc, Aug 24 '19 at 18:06
@RemyTomasetto I only have control over the proxy, and have discovered that the proxy isn't properly receiving the IP of "Alice", instead it is receiving the IP of a load balancer sitting in front of the proxy. — Adam V., Aug 26 '19 at 20:25

jonbo372 · Accepted Answer · 2019-08-23T20:19:22.040

tl;dr Your proxy has to be a so-called non Record-Routing proxy in order to ensure your proxy is not part of any subsequent requests.

Hey Adam,

In SIP, there are a few "magic" headers that control how messages are routed on the network. Route headers are for requests and Via headers are for responses. If you want to ensure that any request follow a certain path through the network, you then need to ensure that you add the correct Route headers to force the requests a particular way (or, in your case, not add route headers). For a new request, the one that is initiated by the UAC (User Agent Client - Alice in this case), the client can just push Route headers onto that request. As that request makes it through other elements on its way to the UAS (User Agent Server - Bob) and those elements wants to stay in the path of subsequent requests, those elements need to add a Record-Route header to the messages, which builds up the Route set which then the UA later will use to push Route headers onto subsequent requests.

So, in short, you need to control the path of subsequent requests by, in this case, NOT adding a Record-Route in your proxy.

Also, if the BYE doesn't reach Alice it is most likely because Alice does not stamp the correct information in the Contact header. Make sure that whatever you stamp there is something that is reachable from Bob (assuming this is the public Internet, then that has to be a public IP address).

If you want to know all details about this stuff, I actually recorded a presentation about this very topic quite some time ago because this is one of the most misunderstood areas of SIP. See: https://vimeo.com/140267478

Thanks for your answer. The video helped me wrap my head around the differences between via & record-route. Part of the problem I'm running into is that the instances where my proxy code runs has `received` set to the load balancer's IP. I'm trying to work around this by adding two `record-route` rows to the headers. The top most one containing the private IP of the server behind the load balancer, and the 2nd to the top most one containing the public address of the load balancer itself. I'm still working through the solution, but in the meantime wanted to reply and say thanks. — Adam V., Aug 26 '19 at 20:23
My previous implementation of this proxy wasn't working because I was adding the proxy to the record-route of the ACK. I was trying to run the proxy on AWS EKS, which didn't pass Alice's IP/port to the proxy. I was seeing the IP of an intermediary node. I tried to work around this by having all messages run through the proxy. In solving this problem I moved the code to AWS ECS + AWS Network ELB. Alice's IP got passed to the proxy code properly. And, b/c the IP gets passed properly, I could remove the proxy from the record route. Now Bob & Alice can send BYEs to each other directly. — Adam V., Sep 13 '19 at 19:17

score 1 · Answer 2 · answered Sep 05 '19 at 15:20

In order to help you, you also should post the INVITE messages. As others mentioned, problem could be the presence of record-route header. It could also be a wrong contact header in INVITE from Alice.

The presence of the "received=" in header via has no effect in the BYE message, only in responses from Bob to proxy (180 & 200 in your case).

score 0 · Answer 3 · answered Sep 04 '19 at 13:15

0

I think the problem is with ACK Alice sent to Bob. It does not have the Contact header, which is used to route new transactions. It can be working wrong. In yor 200 OK, the contact is not the proxy, so the ACK is not passing through it.

To avoid Alice dont send the contact in the ACK, your proxy should do it. I would try to set the proxy inside the contact in the 200 OK:

SIP/2.0 200 OK
[...]
Contact: < sip:12340@proxyIP>
[...]

Doing this, the ACK Alice sent Bob will be received in the proxy and you have to send it to Bob changing the Contact to Alice.

Hope this help. Let me know if it works.

answered Sep 04 '19 at 13:15

Chichoplo

11
1

Chichoplo, the Contact Header in ACK is not needed or even used. From RFC 3261 "Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only target refresh request defined is re-INVITE (see Section 14). " – Kalki70 Sep 05 '19 at 15:26

How do I ensure that BYE messages bypass a SIP proxy?

3 Answers3