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

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.

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

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

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.

Related

SIP SUBSCRIBE receives multiple NOTIFY

I'm writing a SIP client, and I'm having some weird issues when using SUBSCRIBE to an existing client (different, freeware software)
I'm using my own server, but it's not the problem because if I'm doing a SUBSCRIBE from a different client (pjsip), it all works fine.
I'm sending out this SUBSCRIBE message:
SUBSCRIBE sip:3009#10.0.0.4 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.7:5060;rport;branch=z9hG4bKPj3893ccd****************
Max-Forwards: 70
From: <sip:10.0.0.7>;tag=023a965a14a143eb8*******
To: sip:3009#10.0.0.5;tag=8cfb7*********
Contact: <sip:10.0.0.7:5060;ob>
Call-ID: bf5d48fe8ca0***************
CSeq: 14388 SUBSCRIBE
Route: <sip:10.0.0.5;lr;ftag=023a965a14a143eb8*********>
Event: presence
Expires: 600
Supported: replaces, 100rel, timer, norefersub
Accept: application/pidf+xml, application/xpidf+xml
Allow-Events: presence, message-summary, refer
Content-Length: 0
After that message, an OK is received, but then I'm receiving a NOTIFY message for every presence change that the other client did since HE registered to the server.
The problem doesn't happen with different clients..
If it matters, I'm developing on Visual Studio 2008 on Windows 7 64bit
Any ideas?
Thanks!
From the comments the issue seems to be that you are not sending a valid response to the client and therefore it is sending multiple retransmits of each NOTIFY request.
To generate a valid response the key aspect is that you have to set the Via branch parameter and CSeq to the same values as the request, see RFC 3261, section 17.1.3.

SIP getting 407 Response for BYE Request

In my VOIP Application, i am sending Invite request to ( INVITEE_NUMBER ), and getting 200 OK Response when invitee picks up a call,
But when i send Bye request to terminate the call, i am getting 407 Response code from the server, Should i treat it as an Un-Authenticated Response or am i making some mistake.
Please refer the SIP Flow,
Sending BYE Request to INVITEE_NUMBER
BYE sip:INVITEE_NUMBER#SERVER_ADDRESS:PORT_NO SIP/2.0
Via: SIP/2.0/UDP SERVER_ADDRESS:PORT_NO;branch=z9hG4bKe474296b56f64451ba78152b5ecd2e6c;
To: <sip:INVITEE_NUMBER#SERVER_ADDRESS:PORT_NO>;tag=fe65e252-2245-3d98-cec9-31e2f05efe9d
From: "" <sip:MY_SIP_NO#SERVER_ADDRESS:PORT_NO>;tag=1193168134
Call-ID: 0401186002ac45deaebf746061ec29cc
CSeq: 3 BYE
Max-Forwards: 70
Route: <sip:SERVER_ADDRESS:PORT_NO;lr>
Content-Length: 0
Response from server
SIP/2.0 407 Proxy Authentication required
Via: SIP/2.0/UDP SERVER_ADDRESS:PORT_NO;branch=z9hG4bKe474296b56f64451ba78152b5ecd2e6c;rport=5061;received=124.40.244.4
To: <sip:INVITEE_NO#SERVER_ADDRESS:PORT_NO>;tag=fe65e252-2245-3d98-cec9-31e2f05efe9d
From: "" <sip:MY_NUMBER#SERVER_ADDRESS:PORT_NO>;tag=1193168134
Call-ID: 0401186002ac45deaebf746061ec29cc
CSeq: 3 BYE
Max-Forwards: 70
Proxy-Authenticate: Digest realm="vo.packet8.net",nonce="cf319a6e81ade8f6be8d658a6a0e86ca",qop=auth,opaque="",algorithm=MD5
Content-Length: 0
Is this expected, or there is something wrong or Client or Server side ?
In theory a receiving User Agent can challenge any request including a BYE. In addition any Stateful Proxy along the request path can also challenge the request. In both cases the client must re-submit the request with its credentials.
There's nothing I could find in the SIP RFC that deals specifically with authorisation of BYE requests but this quote from "12.2.2 UAS Behavior" does indicate that in-dialog requests do need to support authorisation:
If a proxy challenges a request generated by the UAC, the UAC has
to resubmit the request with credentials. The resubmitted request
will have a new CSeq number. The UAS will never see the first
request, and thus, it will notice a gap in the CSeq number space.
Such a gap does not represent any error condition.
That being said it's very unusual for a BYE request to be challenged and I suspect there are a lot of SIP stacks around that would not handle it correctly. As Frank has intimated I'd be inclined to check the request routing by looking at the Record-Route headers on the OK response and make sure you are sending the BYE to the correct destination.

is SDP sendonly means to open one RTP Audio stream in this case?

I am a newbie to sip/sdp world.
From my understanding of SDP protocol, if we define a=sendonly from sip server to client softphone, the softphone should open one RTP session for listening, but it should not send any RTP packets to destination. Am I correct?
In my case, I can not hear any sounds coming in, and there is a RTP stream to upload audio. Note: I am using the multicast address.
here is a SIP/SDP dump (from server to client softphone):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.8.219:5060;branch=z9hG4bK-d8754z-b394381274917501-1---d8754z-;rport=5060
From: ;tag=d67855ee
To: ;tag=KQQHgQ93Sjg1F
Call-ID: YTExMzkwZDdhMGM1NTJmMDJlMGFiYjgxMGI1ZDNmMDI.
CSeq: 2 INVITE
Contact:
User-Agent: FreeSWITCH-mod_sofia/1.2.0-rc2+git~20120623T054003Z~65b2f2d2e7+unclean~20120623T083401Z
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 265
v=0
o=FreeSWITCH 1340907341 1340907343 IN IP4 224.168.168.168
s=FreeSWITCH
c=IN IP4 224.168.168.168
t=0 0
a=sendonly
m=audio 34567 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
I use another softphone to multicast sound(verify by wireshark) on that address and port.
why can not I hear the sound?
by the way, softphone i am using xlite, the server is freeswitch.
a=sendonly is, as you suspect, a unidirectional stream. The server says that it will send data and will not receive data, so the client must open a listening port. You're doing the right thing.
If you're not getting audio, it might be time to haul out an analysis tool like Wireshark to see if the server's actually sending any RTP data.
is there a specific reason why you configured a multicast address for this communication?
Multicast delivery depends on how your network is prepared for that. Also if your local ethernet switches are configured for IGMP Snooping, they would not pass any multicast traffic unless there's an explicit IGMP Join message from the client. Also the client should be multicast-capable, in order to be able to start receiving multicast traffic in a particular multicast group.

SIP Subscribe Receives 486 BUSY HERE

I am trying to SUBSCRIBE to a watcher list and the server frequently responds with 486 BUSY HERE. However, the RFCs describe 486 as a possible response for an INVITE, which make more sense for this response. At other times, the server does respond correctly - with a 200 OK, followed by a NOTIFY request.
I am working with an ALU IMS core.
Has anyone seen this issue?
My SUBSCRIBE Request:
SUBSCRIBE sip:yyyyyyyyyyy#example.com;transport=TCP SIP/2.0
Call-ID: 81fcd7229c882f230c726e21f16aadc9#10.0.2.15
CSeq: 4 SUBSCRIBE
From: "XXXX" <sip:yyyyyyyyyyy#example.com>;tag=92521573
To: <sip:yyyyyyyyyyy#example.com>
Via: SIP/2.0/TCP 10.0.2.15:5060;branch=z9hG4bK68630e2ec7c21d2e991854010b7f64543332
Max-Forwards: 70
Contact: <sip:yyyyyyyyyyy#10.0.2.15:5060;transport=TCP>;+g.oma.sip-im;expires=3600
User-Agent: My Android Client/OMA1.0
Require: pref
Supported: replaces,100rel,eventlist,timer
Event: presence.winfo
Accept: application/watcherinfo+xml
Route: <sip:yyyyyyyyyyy#z.z.z.z:5060;transport=TCP;lr>
Expires: 3600
Content-Length: 0
The thing to remember with SIP response codes is there are no hard and fast rules about which specific response code should be used in all situations. Invariably a real World error condition on a SIP server or UAS does not fall neatly into the definition of one of the SIP failure response codes so the closest one is used and the status message may be customised and/or a Warning header added.
The 486 response is a little bit unusual for a SUBSCRIBE request but it could easily make sense. For example if the SIP notification server maintaining the subscriptions has a limit on how many active subscriptions it will maintain or if it's overloaded and doesn't want to process subscription requests for a while.
I'd have a closer look at the 486 response and see if there is a Warning or any other informational type header. Also check whether the response is coming from the intermediate proxy you are using or the end server.
486 is not a response code define in RFC3265. You need to trace your server (if possible) to understand why it decided to send such an unexpected error code.
Sorry for not being much help. I have been working with SIP for several years and never heard of a 486 response for a SUBSCRIBE request. When you find out the reason I'd like to know about it too.

sip "100 trying" instead of "180 ringing"

I develop a software using Microsoft Unified Communications and c#. I'm using a IMVoipSample as a code base. As a voip backend i'm using asterisk. Everything fine, i can register, make calls, accept/reject incoming calls. There is a one thing that i cannot resolve.
while i make a call to a 3rd party softphone there is an answer from it:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.250.29:5060;branch=z9hG4bK786d156c;rport=5060
Contact: <sip:6011#192.168.246.203:45134;rinstance=7af05ded7e7e49e6>
To: <sip:6011#192.168.246.203:45134;rinstance=7af05ded7e7e49e6>;tag=9a00d038
From: "6012"<sip:6012#192.168.250.29>;tag=as66995cd4
Call-ID: 7cebe5d1060b11452571a22e0e2cb919#192.168.250.29
CSeq: 102 INVITE
User-Agent: X-Lite release 1002tx stamp 29712
Content-Length: 0
But when i make a call to my IMVoipSample phone there is an aswer:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.246.203:45134;branch=z9hG4bK-d87543-71570d1c6127bc7a-1--d87543-;received=192.168.246.203;rport=45134
From: "6011"<sip:6011#192.168.250.29>;tag=18345648
To: "6012"<sip:6012#192.168.250.29>
Call-ID: fd7f305d6520cd53YjQ2ZDJmMDAwZDE0YmUwMjRlMGFmM2NmODg5OGM1ODQ.
CSeq: 2 INVITE
Server: Asterisk PBX 1.6.2.9-2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:6012#192.168.250.29>
Content-Length: 0
I have a samsung officeserv pbx, it is connected to asterisk, i can make calls to softphones and vice verca. But the audio difference of making calls to softphone and my IMVoipSample phone is there is no normal connecting beeps, only silence. I suppose it is because of "sip 100 trying" instead of
"180 rinning".
So the question is:
do I need setup additional signalling of ringing in client?
1xx responses are informational responses and in the case of 100 Trying are optional. SIP User Agent Servers (UAS) will generally respond with a 100 Trying response immediately when they receive an INVITE request to let the User Agent Client (UAC) know they are processing the request and to avoid retransmits. At some time later they will follow the 100 Trying response with a 180 Ringing or 183 Session Progress. Once someone or something answers the call a 2xx response needs to be sent, typically 200 Ok.
If your softphone software is only generating a 100 Trying response and not the subsequent 180 Ringing response then my guess is you have missed a step. At the very least if the softphone has a problem and can't generate a ringing response because there is nothing to ring it should generate a 4xx error response.
Well, i solved my issue by explitic adding ringing in sip.conf of asterisk
exten => _6.,1,Ringing
exten => _6.,n,Dial(SIP/${EXTEN:0}).
but #sipwiz gave a detailed description of the source of problem