I am new to sip protocol.I understand the normal sip mechanism like how it works.I know about sip re-invite method which is useful to update the SDP(Session Description Protocol) parameters.But recently i found UPDATE sip method which also do the same thing.my questions are
1) Why we need UPDATE sip method?
2) Which phones(like zoiper,sjphone) are sending this UPDATE request to the servers for SDP parameter changes?
Any help would be great.
Thank you
Your answer can be found in the abstract of RFC331 - The SIP UPDATE method:
UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.
To learn which phones can utilize UPDATE you'd best read the manuals.
Related
I'm trying to understand how forwarding should work in an IMS deploy. Forwarding is performed by an AS in the middle of the SIP path, for example when the original called subscriber doesn't answer the call. In that case, the AS cancels the call (sends a CANCEL), and sends a new INVITE to the forwarded user. Before sending the CANCEL, however, the original called party has already issued his SDP answer in a reliable manner (183 with 100rel).
In the new INVITE, the SDP offer from the original calling party is used, and the forwarded user sends his own SDP answer, that obviously, differs from the original called party. the AS, when receiving this answer, and since it already sent the answer from the original called party, instead of just relaying this new answer, sends an UPDATE to the calling party, with the new answer. The UPDATE is accepted by the calling party and later on the call is established.
What concerns me is that according to RFC 3264, section 8 "Modifying the Session":
When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP.
In this case, looking at the trace, the SDP issued in the UPDATE is completely different, including the o= line, as it comes from a different agent. Should the AS manipuate the SDP of the new SDP answer to hide the fact that it comes from another UA? Is there another more standard way for this flow?
Thanks for your insight.
What concerns me is that according to RFC 3264, section 8 "Modifying
the Session":
When issuing an offer that modifies the session, the "o=" line of the
new SDP MUST be identical to that in the previous SDP, except that the
version in the origin field MUST increment by one from the previous
SDP.
Provided this is the same SIP endpoint or B2BUA. see below the rational.
In this case, looking at the trace, the SDP issued in the UPDATE is
completely different, including the o= line, as it comes from a
different agent. Should the AS manipuate the SDP of the new SDP answer
to hide the fact that it comes from another UA? Is there another more
standard way for this flow?
UPDATE method can serve several purpose :
Change the signaling information (let's say SIP headers)
Change the media information (let's say SDP fields)
Update both at the same time.
You are in the third case, the SIP endpoint has changed so the SDP must be different.
From the AS point of view, 99% of the time the AS must be transparent to those changes and act as a pure SIP proxy BUT there are some specific cases where it may act as a B2BUA and hide that from the caller using RTP proxy.
I am currently learning Session Initiation protocol. In that, started learning basic call flow of session Initiation Protocol. While studying that, in one source there mentioned that BYE request method is hop by hop,but in another source there mentioned that BYE request method is end to end. So now I am bit confused with that, Whether BYE request method is hop by hop or end to end??? Anybody help me out this. Also refer a good source for sip protocol.
Since a SIP BYE can only be a mid-dialog request (neither SIP UA pertaining to the dialog is allowed to send a BYE before the INVITE transaction completes or if the final answer is non 2xx), it logically follows that it can only be routed using the dialog's routing set -- according to RFC 3261, this mechanism is dubbed "loose routing". Now, since "loose routing" logically conflicts with "hop-by-hop routing", it follows that BYEs can only be "end-to-end" requests.
Welcome to the wonderful SIP world!
I suspect you have encountered a typo between BYE and CANCEL :
BYE is end-to-end and may be authenticated (servers may attempt to challenge in protection of fake BYE)
CANCEL is hop-by-hop.
There is some books available but I do not want to suggest one; have a look to 'living' web resources and RFC. Start to have a look to http://www.networksorcery.com/enp/protocol/sip.htm
and tech-invite
and do not hesitate to look RFC(s) of call flows like RFC6337 Session Initiation Protocol (SIP) Usage of the Offer/Answer Model.
I'd like to integrate some phone status information into our crm system (calling, on the hook, busy etc). I would prefer not to build and maintain a fully functioning SIP server because i only need very basic information. Also, our VOIP provider already maintains a fully functioning SIP server, and they are way better at it. Basically, I would my crm sever to be kept up to date on anything the phone does? Would it be possible for our crm server to receive any SIP messages the phones send to our VOIP provider.
Can I tell a sip phone to do that?
Is such a feature supported by many phones?
Am i looking at this in the wrong way? I'm completely new to SIP and phone integration so there is a good chance there is an easier or better way to do this.
Thank you for your help!
You might use phone feature called Action URL. It is generating HTTP GET requests on events like on hook / off hook, these request can be used to pass events to CRM.
I have a question about integrating with a phone company (the Provider) using SIP.
I have a situation:
1. A call is made to a PSTN number
2. The Provider forwards the call to a SIP Gateway
3. Twilio is the SIP Gateway, so I receive an HTTP request for every new call
4. I execute my application logic
As I understand the SIP integration between the Provider and Twilio is done using SIP INVITE.
Now a have the challenge is to implement the integration using SIP REGISTER.
As I imagine, the scenario should look like this:
1. I register against the Provider using SIP REGISTER
2. A call is made to a PSTN number
3. The Provider gives me the call
4. I execute my application logic
I need to figure out what is needed in order to accomplish this:
Firstly, does this scenario make sense?
Do I need to use a PBX solution (like Asterisk, FreeSwitch) to implement SIP REGISTER and build my application on top of it?
If so, which PBX solution do you recommend and which features/modules are needed? And do I have to host it on my server?
Perhaps I don't need a PBX solution, and a library is enough as described here?
It is the Provider pushing for this way of integration and I have too little knowledge about it.
What I have figured out is that Twilio can't help me with this. So it looks like I have to take a part of solution in-house.
REGISTER is required if your terminal or terminals belong to the domain of a VoIP provider.
REGISTER records the mapping between the identity the VoIP provider gave you and the actual address and port where you will be listening for requests.
This way, calls addressed to you (sip:myuserid#voip.domain.com) will be sent by the VoIP provider to the address of record it has for you.
If you are a VoIP provider yourself (i.e. you have a sip:myuserid#myowndomain.com), then your peer voip providers will route requests to you based on DNS records or internal domain-based routing decisions. Once the call reaches you, then you can decide on how to handle it. If you are a real SIP provider, then you will have a registrar where you store the result of the REGISTER of your different users.
If you want to implement some application logic on your end, you have different options:
Easiest way is to implement a UAC/UAS, basically a terminal. Your application is the terminal, it registers with the VoIP provider and receives all your calls. You will just need the SIP stack, and you can do whatever you want with the call.
Using a PBX software. Basically it will handle normal calls for you, and the REGISTER when needed. Typically they will have APIs to perform some degree of automation/modification of the call handling.
Difference between the approaches, in the first case, you just have the protocol, so you must do everything else. In the second case, the objective is to process normal calls and they will offer you some window (smaller or greater) to see into those calls and do things with it.
It's not clear how to use jain SIP stack in mutli-thread environment. I need to create multiple SIP sessions from different threads, e.g each client should be proceeded in its own transaction. Below is few options:
Use single SipProvider for receiving and sending SIP requests and do multiplexing on application side. SipProvider is not thread-safe, hence sending requests requires proper locking.
Create new SipProvider and new ListeningPoint for each client. This is how it works for me now. However, I don't really like it. And it's not clear, whther SipStack threadsafe or not
Create new instance of SipStack for every client
Its been a long time since I thought about JAIN-SIP (or even SIP for that matter or even Java) but here goes:
Set the re-entrant listener flag when you create the stack. (look up the javadocs). Specify a thread pool size. When a sip request or response comes along, the stack may potentially create a new thread for you and invoke your listener.
Your critical section is the SipListener implementation. You should not block for ever in it - otherwise new inbound requests and responses will not be routed to the sip listener for the transaction that is being processed at the time you blocked.
Hope that answers your question. Happy hacking.
Thats it.
why don't you ue SIP Servlets, it lets you focus on your application logic and handles those details for you ?
See http://code.google.com/p/sipservlets/