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.
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 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.
I'm writing simple SIP-proxy application which stands between Astreisk and SIP client (any softphone). The purpose of the application is to calculate the duration of the call.
Below is example of regular flow:
Client sends INVITE to SIP-Proxy, SIP-Proxy resends INVITE to Asterisk
Asterisk answers with 200 OK, SIP-Proxy resends 200 OK to client.
Client answers with ACK, SIP-Proxy resends ACK to Asterisk
Whenever one of the parties sends BYE, conversation should be finished.
On step 2 I assumes that call is started (e.g. rtp media flow is started). Then I wait for BYE message to calculate duration of the call. However I noticed that some clients never goes to step 3 and 4. No call end notification received from any parties after step 2. And duration of such call is infinitely.
What is the best way to find out start/stop time of the SIP call without sniffing RTP flow ? Should I wait for step 3 to mark the start of the call ? What if client omit ACK or what if UDP datagram with ACK is missed in the network ?
For now I used to think there is no reliable way to figure out that SIP call is started. Maybe I should use Astrisk channels API instead to track active calls.
Another option is to generate a RE-INVITE to test the existence of the Session. Dont have to negotiate a timer or anything. Just using re-invite could help. Reuse the SDP to ensure that no media changes happen. But then your application is moving out of being a Proxy in the path of the call to being a application server.
Also the duration can only be capped to nearest interval for this re-invite request and not necessarily the exact time the call was released.
Your problem seems to be at SIP level, because your proxy does not add itself into the message path using a Route header. This process is called Record Routing. If doing so, all subsequent requests in your dialog will also traverse it (ACKs and BYEs included).
You should not reinvent the wheel by writing a SIP proxy. For example, you could use a open-source, flexible, powerful and completely customizable SIP Proxy in order to build any possible scenario you could think of: OpenSIPS!
I am not overly technically savy so I am asking the community if this can be done.
I am using ONSIP.com as a hosted PBX solution. ( Its easy and I like their interface.
What I would like to do is use their "bridge function" to have Twilio be the source for my SIP numbers.
I think this can be done because ONSIP describes how I can get an international number from DIDWW>com and have it "pointed" into to my system. So I thought, why not have Twilio supply me with numbers, local and international.
The real question I have though is can I make calls out on that SIP number, going through ONSIP.com to start the call but have Twilio actually make the call , (if that makes sense)
ONSIP.com charges 2.9/minute in or out bound and it appears as though Twilio is on 1/minute. so it would seem to make sense to do this if it can be done?
Here is their info on an inbound bridge
http://www.junctionnetworks.com/knowledgebase/onsip/admin-portal/apps/inbound-bridge
Thanks for any advice or input you might have on this subject.
What you need to find out is if OnSIP and Twilio both support SIP transfers.
To have a call you've started on OnSIP's server "moved" to Twilio it will require the use of SIP REFER requests, which are how call transfers are done in the SIP World. Without a transfer it means your call would end up going through both OnSIP's and Twilio's server and mean you end up incurring both sets of charges.
I suspect you'll find one or both of them don't support transfers since such functionality can be tricky for a SIP provider to implement and it's also it's not going to be in the originating provider's interests, in this case OnSIP, to provide you with a way of avoiding their call charges.
Perhaps an easier way for you would be to get an IP Phone or ATA that has two or more SIP lines and connect the first line to OnSIP for incoming calls and the second line to Twilio for outgoing calls.
For anyone who finds this now, Twilio does not support Sip Refer at the time of this post
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/