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.
Related
I have a question regarding "Supported:histinfo" in incoming INVITE.
If the following example is a valid INVITE message? That is, it has "Supported:histinfo", but it actually uses Diversion header.
What does "Supported:histinfo" means? Only means the sender supports History-Info?
INVITE sip:7654321#xx.xx.xx.xx:5060 SIP/2.0
Supported: histinfo
Diversion: <sip:+12345678#1.2.3.4;user=phone>;reason=unconditional;counter=1
From RFC4244,
A new Supported header, "histinfo", is included in the Request to
indicate whether the History-Info header is returned in Responses
(BACKWARDS-req).
So, seems that the above example is a valid one.
Thanks,
Ted
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.
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.
Sorry in advance for the newbie question.
I am using ASIHTTPRequest to send and receive packets.
However, when I send a packet from the client to the server, the packet has a header attached to it:
POST / HTTP/1.1
Host: 192.168.0.6:8080
Accept-Encoding: gzip
Content-Length: 64
User-Agent: ASIHTTPRequestTests 1.0 (iPod touch; iPhone OS 4.1; ko_KR)
Connection: close
PACKET_TESTM0001
The only information I want my client to send is: PACKET_TESTM0001
Is there a way to remove all the above header (All lines including POST to User-Agent)
Thanks in advance for your helpful response.
That header is required by the HTTP protocol, so better you don't remove it or your web server will not accept the request.
If you do no want to use the HTTP protocol (i.e., you do not want to talk to a web server), then you can use NSStreams with sockets.
There's some confusion here between "packet" and "HTTP request". Googling those two terms would probably be enlightening for you.
ASIHTTPRequest makes, as the name implies, HTTP requests. It wants to be talking to an HTTP server, and then probably to some sort of server-side code to process the request.
Have you rolled your own server, here? Because you're not doing what is expected when you're talking HTTP.
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