I am trying to use Jain Sip to create a sip user agent, which can receive INVITE/ ACK/ BYE, and send back the response with SDP if necessary.
It can receive INVITE, send OK response, receive ACK and then do RTP packet transport. But when it receives BYE from the other side, a 481 will be thrown by Jain Sip itself.
I was sending response statelessly by using SipProvider.sendResponse(response). And it turns out if I switch to stateful (getNewServerTransaction from incoming request, then use SipServerTransaction.sendResponse), everything works. So I am wondering what is the difference between them? Is there anyway I can do this statelessly?
Basically when stateful the JAIN-SIP stack allocates its own resources to run the SIP state machines for transactions and dialogs. As you can imagine if you do it only partially for a call it will get out of hand. My guess is you have automatic dialog support turned on and you are mixing stateful and stateless mode in some way. If you want to go stateless make sure there is no auto dialog. Best way to debug is to see DEBUG logs and code.
Related
I am testing the integration of a SIP Server(just a PBX) with another PBX.
The incoming call comes into the PBX and is sent to my SIP Server.
Once the call arrives on my SIP Server, it is then again sent back to a user who is registered to my PBX. Here we have 2 call legs – one from the caller to PBX and another from Sip Server to called party.
The call is set up correctly and there is no issue with audio as well.
When the called party releases the call, my SIP Server sends a BYE message to called party and caller in the same TCP packet.
Upon running a Wireshark trace I found that BYE message from my SIP Server reaches the called party but never reaches the caller.
I know there is a firewall between my SIP Server and PBX.
Question:
Is there an option for how to prevent multiple SIP messages in a single TCP packet? Other than using UDP or fight against FW?
>> BYE from SIP Server to called party and it gets a 200 OK:
11:39:03.163: Sending [31,TCP] 462 bytes to 10.cc.dd.ddf:5060 >>>>>
BYE sip:+xxxxxxxxx#10.xx.cc.vv:1122;transport=tcp SIP/2.0
Call-ID: 003BA5CE-58A9-1D9C-ACEB-886231C0AA77-57379#1xx.vv.vv.vvv
<................>
>> BYE from SIP Server to the caller and it never makes it to the PBX:
11:39:03.163: Sending [31,TCP] 448 bytes to 10.cc.dd.ddf:5060 >>>>>
BYE sip:+420702252645#10.cc.cc.bb:5060;transport=tcp SIP/2.0
Call-ID: acda8080-da917a0e-5a26b-8a61610a#10.xx.cc.vvb
Is there an option for how to prevent multiple SIP messages in a single TCP packet?
While the setup your describe is confusing (images with setup and message flow might make it more clear) and the question by itself is likely off-topic (unrelated to programming), this specific part of the question can be answered:
There is no option like this in SIP. While your specific but unknown endpoint or PBX might have such an option it is unlikely. The sender is fully within the specification if it packs multiple SIP messages to the same hop (i.e. SIP endpoint or SIP proxy) into the same TCP connection where they also can end up in the same packet because this is how TCP works. If the recipient has problems with this then it is a bug in the recipient and should be fixed there instead of working around it in every possible peer.
"What will happen in SIP if both parties send INVITE to each other at same time"
What will be the behavior in the above case?
Which call will Process?
The received first INV may be proceed to establish the call by the SIP Proxy, whereas the received second INV maybe rejected by a 4xx response. But since SIP is session based it is also possible that the Proxy can establish both calls. But one call should be in hold state. Only one call will ve active.
The most likely behaviour is that the SIP user agents would display a new incoming call.
Since they would also both have an outgoing call in progress it would be up to the user as to whether they would answer the incoming call or ignore it and persist with their original outgoing call.
The crucial point is that the two INVITE requests are independent. It would be the same as if two people called each other on their mobile phones simultaneously.
RFC 3261 section 14.2 says
A UAS that receives an INVITE on a dialog while an INVITE it had sent
on that dialog is in progress MUST return a 491 (Request Pending)
response to the received INVITE.
So, I think both the parties will generate 491 response to each other. But I am still not sure as both of these INVITE will be part of different dialogs and standard mentions on the same dialog.
Initially I was looking for an answer to why ACKs to 2xx responses form a separate SIP Transaction, while ACKs to non 2xx responses don't. Google gave me this:
"When the UAC receives 200 OK, the client transaction is destroyed at TL.
This is done because, the TL is unaware of the above core. The above
core can be a Proxy or an UAC core.
In case of proxy, the 200 OK is forwarded whereas in case of UAC, an
ACK is generated. Now this ACK has to
create a new transaction (transaction created by INVITE had been
destroyed)at TL for its transmission, hence the ACK for 200 OK is
outside the INVITE transaction.
For other non-2xx final responses, the client transaction at TL is not
destroyed and the ACK is generated by TL.
Hence in this case, the ACK is within the transaction."
http://sipforum.org/pipermail/discussion/2011-June/008499.html
Now my next question was why is the client transaction destroyed at TL upon reception of 200 Ok. Is it because ACKs are sent directly to UAS without passing intermediate proxies? (so proxies will never know if the INVITE transaction is actually completed).
Another possibly related issue I am having is that I don't understand why retransmission of 200 OK is done end-by-end. Is there a reason why retransmission is not done in hop-by-hop manner?
The philosophical answer as to why SIP uses different ACK mechanisms is to discreetly torture anyone foolish enough to dig into the bowels of the SIP standard.
Why is 200 OK retransmission handled by UAS?
The answer is detailed in the SIP RFC Chapter 17 Transactions (which is also referenced in the sipforum link your provided).
The reason for this separation is rooted in the importance of
delivering all 200 (OK) responses to an INVITE to the UAC. To deliver
them all to the UAC, the UAS alone takes responsibility for
retransmitting them (see Section 13.3.1.4), and the UAC alone takes
responsibility for acknowledging them with ACK (see Section
13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction.
Putting it another way the SIP designers were worried about the reliability of 2xx responses being delivered over UDP so they decided sending an ACK request from the client (UAC) to the server (UAS) was a good way to implement retransmissions.
I've never really understood why SIP couldn't just use the same mechanism for 2xx and non-2xx ACK's. It would make the job of implementors easier.
Now my next question was why is the client transaction destroyed at TL upon reception of 200 Ok. Is it because ACKs are sent directly to UAS without passing intermediate proxies?
If the INVITE request traversed a SIP proxy or proxies then it's likely that the ACK request will traverse the same proxies (a 2xx response can change the proxies used in subsequent requests within the same SIP dialog so in theory the ACK could traverse different proxies). So no the ACK request handling at the client (UAC) is not designed to handle requests travelling different SIP routes.
Another possibly related issue I am having is that I don't understand
why retransmission of 200 OK is done end-by-end. Is there a reason why
retransmission is not done in hop-by-hop manner?
Because the SIP standard mandates that the responsibility for INVITE response retransmissions is handled by the UAS. A stateless SIP proxy does not have UAS capabilities, it simply passes any requests or responses it receives through to the next SIP agent.
However just to confuse things, a stateful SIP Proxy or a B2BUA may very well implement UAS functionality and in those cases the retransmission will occur on a hop-by-hop basis although in that case each INVITE transaction is between the UAC and the UAS in the Proxy or B2BUA rather than a UAS in the destination SIP client.
Tried to explain the same in the following link
https://abhishekchattopadhyay.wordpress.com/2010/09/21/why-ack-is-a-separate-transaction-for-invite-with-a-successful-200-ok%C2%A0response%C2%A0/
As such the question "why ack is a separate transaction in case of a 200 OK" is not a question at all. This is already explained in 3261. 200 OK (for that matter any final response) is supposed to end the transaction. And so new request would be a new transaction. no surprises!!
the real and uncomfortable question is why is ACK part of the invite transaction if the response is anything but a 200 OK. Read the above link the reason is put down there.
Thanks.
Why is 200 OK retransmission handled by UAS?
The answer in clear for me in RFC 3261 page 128:
"The handling of this response depends on whether the TU is a proxy
core or a UAC core. A UAC core will handle generation of the ACK for
this response, while a proxy core will always forward the 200 (OK)
upstream. The differing treatment of 200 (OK) between proxy and UAC
is the reason that handling of it does not take place in the
transaction layer."
I also think this question for a while and it's clear for me when I think about proxy in the communication path. As we know, non-2xx response take place in the transaction layer. The transaction layer on proxy will response a ACK for the non-2xx response. Also the transaction layer will resend ACK when receive non-2xx again.
Let's suppose, if 200 OK take place in the transaction layer. The proxy transaction layer will response a ACK. The session will be created on UAS. This is no problem if 200 OK can reach to UAC finally. But, that's not the result we wanted as 200 OK may not reach UAC for some other reason.
I don't know enough about SIP. As far as I know SIP can not be used in LAN. But it's features are very good. I want to use it for a LAN messenger (with video conference facilities).
Is there any way of using SIP in LAN network ?
The SIP protocol can be used over any reliable transport (TCP, XMPP, instant messaging channel, etc...) to a service (e.g. a server such as a SIP proxy) that knows how to route the SIP INVITE message from the caller to the callee. e.g. If you send an INVITE to bob#foobar.com, there's needs to be a service that knows how to find "bob" and deliver the message. Likewise, when Bob sends back his response messages back, the messages need to route back to the caller who sent the original INVITE.
And you can do SIP without a server - provided the computer already have a connection (direct or indirect) to the other computer intended for the call.
But SIP isn't anything special. If you were to invent your own video conferencing protocol, it would probably look a lot like SIP. SIP's primary job is for both sides of a call to exchange IP/port candidates for connecting directly in addition to codec and bandwidth negotiation data.
After the SIP messages are exchanged, ICE/STUN/TURN take over and RTP packets typically flow. SIP isn't used in the call except to end the call.
What are you really trying to do anyway?
Thread is Old but still I would like to contribute to this. There are various SIP server like http://www.officesip.com/index.html which works in LAN and can be connected to hardware phone too and soft client also.
Jitsi is open source cross platform SIP/xmpp client:https://jitsi.org/
And if you want to XMPP server Openfire is the best:http://www.igniterealtime.org/projects/openfire/
I hope this will definitely help someone..!
I am trying to make a gateway between SIP and XMPP domain. I have an environment with FreeSWITCH (with dingaling module) and OpenFire (FreeSWITCH is registered as a component in OF). Calls from XMPP to SIP are working fine. The problem appears for calls from SIP to XMPP. The caller (SIP) has a ringing tone, the callee (XMPP) has a 'connecting...' message after answering the call. The connection (voice channel) is never established.
Do you have any experience in making calls between SIP and XMPP users and have an idea, why it is not working?
Thanks in advance,
Maciek
Enable debug in mod_dingaling and mod_sofia and look for XMPP/Jingle errors.
However I suspect NAT/Firewall/Connections issues for this half-working behaviour.