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

1
votes

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

enter image description here

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:[email protected]>;tag=I9jUO6GotuK.DLbMUK9.HRKStDfVA18r
To:  <sip:[email protected]>;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:[email protected]: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:[email protected]:5090 SIP/2.0
Via: SIP/2.0/UDP 192.168.168.103:58922;rport;branch=z9hG4bKPjKxiikjcMSTNLKavscYpxTToZfOn7AlCI
Max-Forwards: 70
From: "Alice" <sip:[email protected]>;tag=I9jUO6GotuK.DLbMUK9.HRKStDfVA18r
To: <sip:[email protected]>;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.

3
sipsip-server
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
@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.

3 Answers

1
votes

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

0
votes

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).

-1
votes

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.