Hi Every one...

Can any one tell why a 3 way handshake is required for INVITE ???even though SIP can
be tramitted over TCP
I assume you are talking about a TCP 3 way handshake when you refer to the SIP over TCP. That
3 way handshake establishes communication at the network transport layer and not at the SIP
application layer. To establish a call, you will still need a SIP 3 way handshake at the application
layer.
Hi,
There could be several reasons for three way handshake needed for INVITE. Some of them are:
1. Three way handshake is a procedure to synchronize requests and responses. It is used even
in TCP as well.
2. It may not be possible to establish VoIP call just with INVITE/200 OK. Some times mis-matches
in SDP negotiation needs confirmation from caller or calle. These can be sorted out by having
ACK message.
3. Media negotiaton offer/answer model needs both parties agreeing on common media codecs
and formats. There is a possibility that one party sends its capabilities and other sends in
different format (With priority). Caller may not agree and would like to have his own priority. ACK
message will help in this.
My assumption is that caller and calle sync up may not be achieved just with INVITE/18X/200OK.
Needs final confirmation from Caller if there is a disagreement.
And also ACK is a response to 200 OK. It is kind of response to 200 OK.
Rgds,
Narasimham.
may be this can help you to understand why we require Three-Way handshake in invite message.

INVITE is the only method that uses a three-way handshake as opposed to a two-way handshake
(METHOD-final response). Certain characteristics set the INVITE method apart from other methods. When
a client issues a request other than INVITE, it expects a fast response from the server. However, the
response from an INVITE request might take a long time. When Bob calls Laura, she may have to fish her
SIP phone out of her coat pocket and press buttons, so the 200 OK response that will come will be more
or less delayed. Sending an ACK from the client to the server when the response is received lets the server
know that the client is still there and that the session has been successfully established. The three-way
handshake also enables the implementation of forking proxies. When one of these forks a request, the client
who issued the request will obtain several responses from different servers. Sending an ACK to every
destination that has responded is essential to ensuring SIP operation over unreliable protocols such as UDP.
Besides the speedy session setup and forking, INVITEs three-way handshake also enables us to send an
INVITE without a session description, which will be sent later in the ACK. This feature is useful, for
example, when SIP interworks with other signaling protocols that use different message sequencing

Allow: Allow header is used to mention what methods an UA does support. And this methods can be used
in that particular dialog. If the Allow header is not present, then it doesnt mean that UA wont support any
methods.
Ex: Allow: INVITE,BYE,CANCEL.
Supported: It says what extensions can be supported by an UA.
Ex: Supported: 100rel
Require: It lists all the extensions that other UA must support in order to process the request. Another
similar header Proxy-Require is also there. In this case Proxy should support the extensions listed to
process the request received.
Options : Its a method which is used to query the capabilities of the other party. Say if want to know
whether or not the end party supports G711 codec (it can also query Method, Extensions etc.), you can send
OPTIONS method querying the capabilities. In this scenario no need to send INVITE. This is one of the
advantages of OPTIONS method. I think its mandatory that every UA should support OPTIONS.

I plan to send 500 "No Soundcard". Because in my case no problem in SDP.

so 500
is the best response from UA2.
I'd agree on this.
415 means it doesn't understand sdp (not true)
488 means it didn't agree codec selection (not true)
488 also, to me, also implies that some other codec might work (not
true)
If there are no other sound cards, then I'd agree that
500 is more suitable that 415 or 488:
21.5.1 500 Server Internal Error
The server encountered an unexpected condition that prevented it from
fulfilling the request. The client MAY display the specific error
condition and MAY retry the request after several seconds.
If the condition is temporary, the server MAY indicate when the
client may retry the request using the Retry-After header field.
If there are other sound cards that can support other codecs then 488 is
best.
Regards,
Attila

Why not "500 No Sound Resource"?

On Wed, Apr 1, 2009 at 11:02 PM, Dushyant Dhalia
<dushyant.dha...@rancoretech.com> wrote:
> Since there's no sound card in UA2 and if the corresponding session
> requires voice to be one of the media in the session then UA2 is not
> capable of handling this particular call. In such a case either 415 or
> 488 can be sent. In response UA2 should send the media-type it still
> supports. In can use Accept, accept-enc or accept-lng headers or the
> message body to intimate the media type it supports.
>
>> But in our case there is no SDP problem, Request is not malformed and
user
>> is not busy also.
>> There is no sound card in UA2, so i have to drop 200 OK and need to
send
>> Error Response.?
>> For this case any Error response? Kindly let me know.
>> ?
>> Thanks & Regards,
>> Vijay
>> ?
>> ??
>>
>> 488 : when the offered SDP is not acceptable
>> 486 : when the user is busy
>> 400 : the request was malformed
>>
>> Dear Friends,
>> ? ? ? ? UA1 send Invite to UA2. UA2 sent 180 to UA1, and as per our
one
>> requirement UA2 should not send 200 OK and have 2 send error
Response. UA2
>> have to indicate to UA1, the call has rejected. now could any one
please
>> tell me, what will be the correct Error Response from UA2 side?
>>
>> Thanks in Advance
>>
>> Thanks & Regards,
>> Vijay
>>
>>
>> ? ? ? Connect with friends all over the world. Get Yahoo! India
>> Messenger at http://in.messenger.yahoo.com/?wm=n/
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> "DISCLAIMER: This message is proprietary to Aricent and is intended
solely
>> for the use of the individual to whom it is addressed. It may contain
>> privileged or confidential information and should not be circulated
or used
>> for any purpose other than for what it is intended. If you have
received

>> this message in error,please notify the originator immediately. If

you are
>> not the intended recipient, you are notified that you are strictly
>> prohibited from using, copying, altering, or disclosing the contents
of this
>> message. Aricent accepts no responsibility for loss or damage arising
from
>> the use of the information transmitted by this email including damage
from

Hi all
If any SIP packet got retransmitted because of some reason , do we
need to respond for every retransmitted packet or just accept one and
ignore others? Example: If any SIP server got same PUBLISH packet two
times which is retransmitted,do we need to send back 200 OK for both ,or
send 200 OK for one and ignore the second.? Please help me on this...

To get a clear picture of this, one should have better understanding of

CLIENT & SERVER Transactions. Here is few excerpts from RFC3261.
It explains how the Non-Invite retransmissions are handled at Client and
Server side.
NON-INVITE Client Transaction
Once the client transaction enters the "Completed" state, it MUST set
Timer K to fire in T4 seconds for unreliable transports, and zero
seconds for reliable transports. The "Completed" state exists to
buffer any additional response retransmissions that may be received
(which is why the client transaction remains there only for

Rosenberg, et. al.

RFC 3261

Standards Track
SIP: Session Initiation Protocol

[Page 131]
June 2002

unreliable transports). T4 represents the amount of time the network

will take to clear messages between client and server transactions.
The default value of T4 is 5s. A response is a retransmission when
it matches the same transaction, using the rules specified in Section
17.1.3. If Timer K fires while in this state, the client transaction
MUST transition to the "Terminated" state.
Once the transaction is in the terminated state, it MUST be destroyed
Immediately.

Non_Invite Server Transaction :

When the server transaction enters the "Completed" state, it MUST set
Timer J to fire in 64*T1 seconds for unreliable transports, and zero
seconds for reliable transports. While in the "Completed" state, the
server transaction MUST pass the final response to the transport
layer for retransmission whenever a retransmission of the request is
received. Any other final responses passed by the TU to the server
transaction MUST be discarded while in the "Completed" state. The
server transaction remains in this state until Timer J fires, at
which point it MUST transition to the "Terminated" state.
The server transaction MUST be destroyed the instant it enters the
"Terminated" state
I guess once the the timer is timed out(means Transaction is destroyed),
then further retransmissions will be ignored.
This is how SIP handles retransmissions when the client/server state is
COMPLETED. To know more about its behavior in other
states(Trying,proceeding,Confirmed), you can refer RFC3261(Section:17 Transactions)
Regards,
Murali.

what is the difference between jad and manifest

file?
Manifest file describes the files zipped in the .jar file,
like the name of the game, size.etc,
.jad file is used to install the j2me game on the mobile.
The .jad file while installing the application will look in
the manifest.mf file for the properties of .jar file.
If the mismatch is in jar size values, then the application
will install but the size given in the .jad file is
considered over the size given

Hi All
I have installed SIPp on my machine. I have installed Asterix on my machine.
The machine runs on Windows XP.Is it possible to replicate the bellow scenario
from
a single machine using OPENSER or ASTERIX for learning/testing purpose.
<SIPp UAC>-----<OPENSER(Proxy)>--------<SIPp UAS>

Yes. It is possible to run SIPp UAC, SIP Proxy and SIPp UAS in same machine provided they use
different UDP ports.

SIPP has command line options where we can mention next level IP address and port to be
contacted. It may be need to configure XML files provided by SIPp.
Rgds,
Narasimham.