in RFC6314, section 5.2.1.2, it mentions that after Client_L collected its candidate list, it sends INVITE to Client_R with the list, and then both ends can start connectivity check.
I have a question is that why Client_L can send INVITE to Client_R? or why Client_R can receive those data (candidate list)? I think in this time Client_L should have no address info of Client_R. Thanks your answer in advanced.
https://www.rfc-editor.org/rfc/rfc6314#section-5.2.1
In order for clients to establish a P2P ICE session, they have to rendezvous through a reliable signaling server. The signaling server exists for clients to exchange address candidates in order for ICE negotiation to actually begin. This is typically a SIP server. Although ICE allows for almost anything to be used for exchanging addresses.
When the INVITE is sent out, it gets sent to a server that knows how to forward that message to the other client. When the remote client gets the INVITE, it responds back with a series of SIP messages - one of which is the "180 RINGING" or "200 OK" message that contains the address candidates from the client that received the INVITE.
Related
In HTTP, you can tell the client who asks for example.com/foo/ that it should ask for something.else/instead.
Is there a way to do it in SMTP? That is, if the client sends a message to john#example.com, tell it to send it to jane#somewhere.else instead.
I know that I can receive the message and relay it to jane#somewhere.else. For many reasons I don't want to relay messages via my server. Instead, I want to tell the client that it should send it to another address.
The reasons include:
I cannot notify the client of a failure (well, perhaps this can be done).
My server will be blacklisted if the message was spam.
The destination server will consult blacklists with my IP and not with the original sender's IP, etc.
My motivation is:
If this were possible, perhaps it would be a better antispam measure than greylisting.
My institutional server has no antispam filters, while my personal server uses IP-based blacklists such as Spamcop. After the institutional server has received a message, I can scan the message at the client but it's too late to consult Spamcomp and to inform the sender that the message was filtered out (I consider it a must in any filtering). I wish the institutional server could simply redirect people to my personal server, which is a lot better protected and correctly informs the sender of the problem at the SMTP stage.
Sendmail provides FEATURE(redirect) to handle such cases.
It rejects recipient in reply to RCPT TO: with
551 5.1.1 User has moved; please try <newemail#example.com>
Your email server refuses to accept the recipient with hint, it is up to sending host to generate bounce message to the sender. Spammers may/will get the new email too. I do not know any email servers handling automatically such redirects.
I have not investigated how well it is handled by various email clients and level of details provided in bounce message by various email servers.
I am just curious, what is the fundamental reason to have 200 OK responses from a remote end point to be ACKed by the local end point? RFC 3261 states that it is needed for stability purposes but does not go into details. The only reason that comes to my head is the case with call forking. So, if an AOR is registered at multiple end points and these end points respond simultaneously with a 200 OK message, then an ACK will actually indicate which of the remote parties will participate in a peer-to-peer connection. Is there any other reason to end and INVITE hand shake with an ACK?
It's because SIP needs some responses (only INVITE responses in practise) to be reliably transmitted in situations where the underlying transport is unreliable, such as with UDP.
The ACK request is the way for the (UAC User Agent Client) to let the UAS (User Agent Server) know that it received the final response to an INVITE request. Without employing something like the ACK request there would always be the risk that the UAS response would not get through to the UAC and the call would be left sitting in an incorrect state.
The ACK request doesn't have any specific role in call forking. In the case you've described in a call with multiple end points BYE requests will be sent to any call legs that are not required. ACK requests still need to be sent to any UAS that responds irrespective of whether the UAC wants that call leg to proceed or not.
According to sip protocol when first invite send, sip returns proxy authentication required message (if there are any proxy server available), then client send an acknowledge message. But what happen if the acknowledge message failed to reach the sip server? Server returns forbidden after sometimes and ignore all new invite with authentication header. Also when sip gets multiple acknowledge message it's immediately send forbidden.
If your question is what would the correct behaviour be for a SIP server that has issued a 407 and not received an ACK for it, please see RFC 3261 17.2.1 for the description of the INVITE server transaction.
Sending the 407 moves the state machine into the "Completed" state, at which point the G and H timers have to be be set. When G fires, the 407 response needs to be retransmitted. And if all the ACK messages get lost, then timer H will make the server transaction give up eventually. But if the second ACK reaches the server then that's it. You will have seen two 407 responses, one with a lost ACK, the second one with a successful ACK.
The handling of the subsequent INVITE with the credentials should be entirely independent with the previously described process. The INVITE message with the credentials will constitute a separate dialogue forming transaction.
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 basically writing a XMPP client to automatically reply to "specific" chat messages.
My setup is like this:
I have pidgin running on my machine configured to run with an account x#xyz.com.
I have my own jabber client configured to run with the same account x#xyz.com.
There could be other XMPP clients .
Here is my requirement:
I am trying to automate certain kind of messages that I receive on gtalk. So whenever I receive a specific message eg: "How are you" , my own XMPP client should reply automatically with say "fine". How are you". All messages sent (before and after my client replies) to x#xyz.com but should be received by all clients (my own client does not have a UI and can only respond to specific messages.).
Now I have already coded my client to reply automatically. This works fine. But the problem I am facing is that as soon as I reply (I use the smack library), all subsequent messages that are sent to x#xyz.com are received only by my XMPP client. This is obviously a problem as my own client is quite dump and does not have a UI, so I don't get to see the rest of the messages sent to me, thereby making me "lose" messages.
I have observed the same behavior with other XMPP clients as well. Now the question is, is this is a requirement of XMPP (I am sorry but I haven't read XMPP protocol too well). Is it possible to code an XMPP client to send a reply to a user and still be able to receive all subsequent messages in all clients currently listening for messages? Making my client a full fledged XMPP client is a solution, but I don't want to go that route.
I hope my question is clear.
You may have to set a negative presence priority for your bot..
First thing to know is that in XMPP protocol every client is supposed to have a full JID. This is a bare JID - in your case x#xyz.com with a resource in the end e.g. x#xyz.com/pidgin or x#xyz.com/home (where /pidgin and /home are the resource). This is a part of how routing messages to different clients is supposed to be achieved.
Then there are the presence stanzas. When going online a client usually sends a presence stanza to the server. This informs about e.g. if the client is available for chat or away for lunch. Along with this information can be sent a priority. When there are more than one clients connected the one with the highest priority will receive the messages sent to the bare JID (e.g. ClientA(prio=50) and ClientB(prio=60) -> ClientB receives the messages sent to x#xyz.com). But there are also negative priorities. A priority less than 0 states that this client should never be sent any messages. Such a stanza might look like this
<presence from="x#xyz.com/bot">
<priority>-1</priority>
</presence>
This may fit your case. Please keep in mind it also depends on the XMPP server where your account is located, which may or may have not fully implemented this part of the protocol.
So to summarize: I recommend you to look through the Smack API how to set a presence and set the priority to <0 for your bot client right after it connected.