Can anyone tell me what's the meaning of FMTP and RTPMAP?

What are
their differences?
When ever a dynamic payload type is used in the sdp or when ever
additional information is required to decode, the additional
information
should be given in
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
parameters>]
a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP doesn't
have
to understand them. The format must be one of the formats
specified for the media
a-line in the sdp is an optional field and fmtp is a a-line attribute
which points any specific media attribute.
for example, you can use fmtp as a media attribute to negotiate media
parameters for dtmf.
annex-b is just a variation of G729 codec with Voice Activity
Detection and Comfort Noise Generation support.
The interoperability between G729 B variations;
G.729 Annex-B and G.729A Annex-B
G.729 Annex-B and G.729 Annex-B
G.729A Annex-B and G.729A Annex-B
If initial invite is only support G729 Annexb, you should response it
1 of the codecs above.

Yes.

RFC 3262, section 3, paragraph 19 (last paragraph in section):

The UAS MAY send a final response to the initial request before

having received PRACKs for all unacknowledged reliable provisional

responses, unless the final response is 2xx and any of the
unacknowledged reliable provisional responses contained a session
description. In that case, it MUST NOT send a final response
until
those provisional responses are acknowledged. If the UAS does
send a
final response when reliable responses are still unacknowledged,
it
SHOULD NOT continue to retransmit the unacknowledged reliable
provisional responses, but it MUST be prepared to process PRACK
requests for those outstanding responses. A UAS MUST NOT send new
reliable provisional responses (as opposed to retransmissions of
unacknowledged ones) after sending a final response to a request.
Regards,
G711...........audio codec.
G729 ( G729a, G729b, G729ab ) -----audio codecs and
m=image 35866 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
a=T38MaxBitRate:14400
a=T38FaxVersion:0

In SIP call flow when TCP come into picture and when it'll be
changed from UDP to TCP??explain me with some examples...
Govindraj: By default SIP uses UDP as trnsport layer protocol. Still
it depends upon the number of octets per message. If the message size
is less than or equal to 1000 octets then SIP uses UDP only. If the
message size just above the 1000 octets then sip statck itself try to
adjust it in 1000 octets by compressing technique ( ex: via = v,
call-id = c). Still if the size is beyond 1000 octets then SIP has to
use TCP.
If UAC send BYE during calll setup phase then what would be the
response
for BYE method.
Scenario is:UAC
INVITE- <- - - -<- - - -BYE - --

UAS,
-- - - --- - - -- - - - -- - - --- --

-- - - - ---- - ---- - - - --

-- - - -- - - -- ->
- -- - -- --- - -- - - 100 Trying
- -- - -- --- - -- - - 180 Ringing
- - -- - - -- ->
??????
According to RFC3261, UAC should send Cancel if 200 OK is not
received for a

request. This is not a valid case of sending Bye without receiving

answer.
Answer (rfc 3261: section: 15)
A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY
send a BYE for either confirmed or early dialogs, and the callee's UA
MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early
dialogs. However, the calee's UA MUST NOT send a BYE on a confirmed
dialog until it has received an ACK for its 2xx response or until the
server transaction times out.
The impact of a non-2xx final response to INVITE on dialogs and
sessions
makes the use of CANCEL attractive. The CANCEL attempts to force a
non-2xx response to the INVITE (in particular, a 487). Therefore, if
a
UAC wishes to give up on its call attempt entirely, it can send a
CANCEL. If the INVITE results in
2xx final response(s) to the INVITE, this means that a UAS accepted
the
invitation while the CANCEL was in progress. The UAC MAY continue
with
the sessions established by any 2xx responses, or MAY terminate them
with BYE.

Note : For the callee's UA, it would typically imply a BYE;

presumably,
when the user picked up the phone, a 2xx was generated, and so
hanging
up would result in a BYE after the ACK is received. This does not
mean a
user cannot hang up before receipt of the ACK, it just means that the
software in his phone needs to maintain state for a short while in
order to clean up properly. If the particular UI allows for the user
to
reject a
call before its answered, a 403 (Forbidden) is a good way to express
that. As per the rules above, a BYE can't be sent.

A UAS first processes the BYE request according to the general UAS
processing described in Section 8.2.
A UAS core receiving a BYE request checks if it matches an existing
dialog. If the BYE does not match an
existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction
Does Not Exist) response and pass
that to the server transaction. This rule means that a BYE sent
without
tags by a UAC will be rejected.

In the early dialog establishment, it is better to send Cancel for

the
above scenario, if we send BYE instead of Cancel, then UAS should
send
4XX Response ( It should be 481 response code (Call/Transaction Does
Not
Exist))

HI All,
If UAC send BYE during calll setup phase then what would be the
response for BYE method.
Scenario is:UAC
INVITE- <- - - -<- - - -BYE - --

UAS,
-- - - --- - - -- - - - -- - - --- --

-- - - - ---- - ---- - - - --

-- - - -- - - -- - -- --- -- - -- --- - -- - - -??????

-- ->
- -- - - 100 Trying
- -- - - 180 Ringing
->

I am very much agree with Devaraja.

In the early dialog establishment, it is better to send Cancel for
the above
scenario, if we send BYE instead of Cancel, then UAS should send 4XX
Response ( It should be 481 response code but it can be 487 also.
here is an example.....
Alice

Bob
|
|
|
INVITE F1
|
|----------------------->|
|
180 Ringing F2
|
|<-----------------------|
|
|
|
BYE F3
|
|----------------------->|
|
200 OK(BYE) F4
|
|<-----------------------|
|
487 F5
|
|<-----------------------|
|
ACK F6
|
|----------------------->|
|
|
|
|
In this scenario, Alice establishes an early dialog with the
receiving
180 response. Alice sends a BYE on the early dialog. According to

Section 15 of RFC3261, callee's UA MUST NOT send a BYE on early

dialogs,
but the caller's UA MAY send a BYE on early dialogs.

Is there a standard for a third party voicemail subsystem to notify

the presence server that a user has a new message? How does the
presence server notify a particular user about MWI on a voicemail
engine?
RFC3842 defines an event package for Message Summary &Message Waiting
Indication for SIP. Presence Server can subscribe this event from
voice mail system to get the notification.
One way for the user to get MWI is to subscribe directly to the voice
mail system as per rfc3842. But it's also possible for a Presence
Server to act as MWI notification server as long as the Presence
Server can get notifications from the backend MWI engine
Could you tell me what's difference of proxies, user agent servers,
redirect servers, and registrars?
These are the logical entities in the SIP network but physically all
mentioned server may be or may not be in the single server, its
depends upon the implementation.
On the functionality basis we can say like?

1.
Proxies:- Having capability to route the request/response
to the destination, it can also maintain the status of call (depend
on the stateless/statefull proxies).

2.
UAS:- Other party network element, UAS will get a request
from UAC and will send response for this request. Or simply we can
say a logical entities that generate a response to a sip request.

3.
Redirect Server: is responsible for 3xx response. For
example a person has moved from one network to other network either
permanently/temporarily. So redirect
server will send 301/302 response for that.

4.
Registrar: is used for registration/location update
purpose. for every new equipment in the sip network first we have to
send a REGISTER request to Registrar and registrar will update your
location and contact in the location server.

> How Done Conferencing in Sip??????

Conferencing can be achieve by mixing RTP streams either through DSPs
(hardware) or software. Conference servers are usually standalone
software application or supported by gateways. For example, you have
a conference server installed & configured at extension 1000. People
call into extension 1000, the conference server connect these people
and mix all audio stream in real-time together and sent the mixed
audio streams back to all SIP endpoints. Depending on the
specifications of the conference server, there are things to lookout
for like supported codec, maximum extensions per conference session &
maximum conference sessions supported. I hope this explains...
As I have good knowledge in SIP,I want to start working on IMS.So can
anybody give me a brief idea about IMS,Where it's role and usages.
Please refer any docs/links where I can get a thought on IMS.
http://en.wikipedia.org/wiki/IP_Multimedia_Subsystem
http://www.3gpp2.org/Public_html/Misc/X.P0013009_Call_Flows_VV_Due_11_Sept-2006.pdf
http://www.sipcenter.com/sip.nsf/html/What+Is+SIP+Introduction
(explains the basics of sip)
http://www.enterprisemessagingnews.com/enterprisemessagingnews-7920070212IMSSIPForWidespreadNextGenerationNetworks
Please go http://www.pcbest.net to see the WEB phone.
*
*

Read SIP RFC 3261.

For better understanding, download any user agent and configure

it to a sip server (available at sipcenter) and start working. This
is the best way to learn SIP.
Here is the latest and greatest for SIP call generation (Hammer G5),
to
use for Load and Regression testing.
http://www.empirix.com/products-services/v-load_test.asp
I believe that Zoiper and X-Lite both support iLBC, and Zoiper also
supports GSM.

http://www.voipsa.org/Resources/tools.php
that focus on packet creation and flooding. There's also one on
there called "Spitter" designed for SIP bulk call genarator for
regression and load testing.
We (VoIP Security Alliance)
make this list available so that people can do exactly what you are
doing and regression-test their products with the various securityrelated tools out there.

Can you please tell me the difference between Ringing(180) and

Session progress(183).

As per me, if we receive Session Progress(183), then our media

will start flowing from farend to us and from us to farend. and if we
receive Ringing(180) then our device will generate his own ring on
the phone.

I think you are partly right.

In many scenarios that after receiving the 183 response and doing a
PRACK procedure, another 180 response arrive. In this case, if the
RTP
stream is also sending back, then the originator needn't generate
local ring back tone, otherwise it should play itself.

My personal understanding is that you can get - or not - SDP for a

data
stream in both 180 and 183 responses.
I think that if SDP is present, and you support the codec(s) present
in it,
you should play the RTP stream, and if already generating local tone
then
stop and play it. But I'm not sure this is mandatory...
And in case 180 or 183 come without SDP inside, you should generate
local
ring tone, at least for 180. I would also personally do it for 183,
but I don't think it's that straightforward...
For what I could see so far, 183 seemed to be used mostly when
trunking with
PSTN or other kinds of network, but then it usually came with a SDP,
so it
was possible to play the tones received.
And in the cases it didn't come with SDP, it was usually more or less
synonymous to 180, so it was safe to play local ring tone...
But again, personal experience only, so...
An ACK for a non-2xx final response will have the same branch id as
the original INVITE.
The ACK for 2xx-Invite gets its own unique branch-id as ACk is a
separate transcation.
HTH,
What is the practical purpose of carrying DTMF digits in SIP using
INFO or RTP Payload ?
It is unclear if the question is in regards to the reason for DTMF or

the method used to carry it.

Along the first path of discussion, DTMF signals in the middle of
applications can be distorted, especially when using codecs which
perform compression. Therefore there is a need to have a method to
carry
this in a manner so that they can be accurately reproduced.
This is true not only for IVR type systems (including voice mail
systems) but also for many alarm systems, a case which is often
overlooked.
Alarm systems have multiple ways of transmitting their signals based
on
their design. One of which is using a rigid DTMF sequence, so not
only
does recognizing the DTMF tone become important but also the duration
of
that tone.

A very interesting scenario:

- I have 2 devices that support G722 WBA codec and they are in a
conversation.
- Both these devices support a list of codecs and were set to
'automatic codec negotiation' with G722 as top priority.
- A third device which does not support G722 at all but has G729 (one
of the codecs supported by the initial 2 devices but only with 2nd
priority) calls in.
- Three party calling and conferencing is supported by the platform.
Can these 3 devices talk simultaneously?
It depends which device is conducting media mixing, if anyone of the
2 devices support both G722 & G729 is conducting media mixing, there
should be any issues when the third device joins, unless codec
negotiation fails somehow. Thanks.

Can A call to B party without proxy?

You already stated the solution, and it was the whole point of SIP
from the beginning: end-to-end communications without the need for
service providers or network equipment in the network.
Proxies have always been for route discovery when the calling party
does not know the actual address of the called party. The initial
idea
was the email model, where you might know that Foo works at Example,
so you would try sip:foo at example.com. It is up to example.com's
proxy
to expand that to foos-phone-at-home at phone.example.net. If you
know
the address directly, there is nothing to stop you in the Internet
from sending a message directly to that address. HOWEVER, many folks
break the Internet model by putting in firewalls, NATs, and SBC's. By
definition, to gain access to those poor people cut-off from the

Internet, you will have to go through their B2BUA's. Then again, the
address of the B2BUA is the endpont from your perspective, so if you
know that address (which would be something like sip:user at
sbc.example.net)
then you still do not need a proxy.

Steps to Create Audio File in Ethereal

1.

Open capture file in Ethereal

2.
Left click on udp packets and convert a stream to RTP.
Look
for packet into msw from ingress and then out of msw to egress. Also
locate packets in the opposite direction and convert them to RTP.
3.
Identify all RTP streams in trace:
Statistics
---> RTP Streams ---> Show All and hit enter

Analyze --->

4.
Follow instructions on screen by selecting forward stream
(left click) and reverse stream (hold shift key down and left click
stream). Notice how it selected the streams.
5.
Click Analyse button on screen. Make sure the streams are
selected or nothing will happen. Now click Save Payload button and
it
will give you a screen to create the audio file. Give the file a
name
and with the extension .au.
6.
file.

Bring up the file with file manager and double click the
It will start your media player and play the file.

Kaushal

Can any one tell me the difference between Via header and RouteSet
header.
Via header is used to send the response to a request, but route
header
is used to send a new request within the dialog.
Is Contact header mandatory in register request ?
The REGISTER without contact header is used to fetch the bindings.
So, Contact is not mandatory.

6.2.28 Route
The Route header field is used to provide routing information for
requests. RFC 3261 introduces two types of routing: strict and loose
routing, which have similar meaning as the IP routing modes of the
same name. In strict routing, a proxy must use the first URI in the
Route header field to rewrite the Request-URI, which is then
forwarded. In loose routing, a proxy does not re-write the RequestURI, but either forwards the request to the first URI in the Route
header field or it may forward the request to another loose routing
element. In loose routing, the request must route through every
server in the Route list (but may also route through other servers)
before it may be routed based on the Request-URI. In strict routing,
the request must only route through the set of servers in the Route
header field with the Request-URI being rewritten at each hop. A
proxy or UAC can tell if the next element in the route set supports
loose routing by the presence of a lr parameter. An example is:
Route: <sip:proxy at example.com;lr>
Chapter 10 contains an example of the use of the Record-Route and
Route header fields. Examples of Route header fields constructed from
the example Record-Route header fields in Section 6.2.12 are:
Route: <sip:firewall33.corporation.com;lr>,
<sip:proxy1.carrier.com;lr>
Route: <sip:139.23.1.44 ;lr>
6.1.10 Record-Route
The Record-Route header field is used to force routing through a
proxy for all subsequent requests in a session between two user
agents. Normally, the presence of a Contact header field allows user
agents to send messages directly bypassing the proxy chain used in
the initial request (which probably involved database lookups to
locate the called party). A proxy inserting its address into a
Record-Route header field overrides this and forces future requests
to include a Route header field containing the address of the proxy
that forces this proxy to be included.
A proxy, such as a firewall control proxy, wishing to implement this
inserts the header field containing its own URI, or adds its URI to
an already present Record-Route header field. The URI is constructed
so that the URI resolves back to the proxy server. The UAS copies the
Record-Route header field into the 200 OK response to the request.
The header field is forwarded unchanged by proxies back to the UAC.
The UAC then stores the Record-Route proxy list plus a Contact header
field if present in the 200 OK for use in a Route header field in all
subsequent requests. Because Record-Route is bidirectional, messages
in the reverse direction will also traverse the same set of proxies.
Chapter 10 contains an example of the use of the Record-Route and
Route header fields. The lr parameter is new to RFC 3261 and
indicates that the proxy server supports "loose routing". Older RFC
2543 compliant proxy servers create Record-Route URIs that instead of
the lr parameter often contain the maddr parameter with an address or
host that resolves to that proxy server.
Examples are:
Record-Route: <sip:proxy1.carrier.com;lr>,
<sip:firewall33.corporation.com;lr>

Record-Route:<sip:139.23.1.44;lr>
Diff

b/w NAT and ALG

NAT functions at network layer of the OSI model, any NAT device hides
your ip layer information, doesnt hide your sip layer information,
since SIP works at Layer 5. ALG does that.
As described, NAT simply does address translation at network layer,
however, ALG is capable of altering SIP messages at application layer
as well. In other words, when a SIP message goes through an ALG, you
will notice that all IP addresses and ports in both SIP headers and
SDP are modified.
If you are developing your proprietary NAT traversal logic, you need
to pay extra attention to detect ALG's.
why UAS MUST NOT attempt to send a 100 (Trying) response reliably ..
The 100 trying response is hop-by-hop, that is each proxy on the
signalling path can generate the 100 trying response. Whereas the
non-100 trying response (181, 183) are end to end that is the proxy
only forward the response form UAS to UAC. The reliability mechanism
described in RFC3261 end-to-end, so the 100-trying response, which is
hop-by-hop, is kept out of it.

Via headers are inserted by proxy to allow responses to find

their way back to the client. They have no influence on the routing
of future requests (or responses).

Record route also added by proxy and that have influence on the
routing of future requests (or responses).
Hi ,
The difference between Path and Record-Route is that Path
applies to REGISTER and 200 class responses to REGISTER. RecordRoute doesnt, and can't be defined in REGISTER for reasons of
backward
compatibility. Furthermore, the vector established by
Record-Route
applies only to requests within the dialog that
established that Record-Route, whereas the vector established by Path
applies to future dialogs.

If the proxy server is configured to refuse invite messages coming

from unregistered users, you get 403 forbidden message.
If you make peer to peer calls, you can get "trying" to invites you
send.

Based on the spec, the CSeq numbers should increase monotonically

from the previous requests within the same dialog.

>
> Requests within a dialog MUST contain strictly monotonically
>
Increasing and contiguous CSeq sequence numbers (increasing-byone) in each direction.
>
> It is possible for the > CSeq sequence number to be higher than
the remote sequence number by more than one.
>
> So based on what is said above, the CSeq number MUST be higher
between
> multiple requests. Now does this rule hold on the direction of
> requests in a dialog. Example as follows:
>
> A--------------Invite( Cseq = 101 )------------>B
>
<-------------200OK--------------------------->
----------------ACK----------------------------->
> At this point, B wants to change the session parameter and sends a
new
> offer.
>
> <----------------Re-Invite ( CSeq = 101 )-------> --------------------------200OK------------------------->
> <-----------------------ACK----------------------------->

Each end of the dialog has its own CSeq sequence. They are
independent.
The first time B (in your example) sends an in-dialog request, it
makes a new CSeq up that has nothing to do with the CSeq that A
chose.
After that it increments its CSeqs as it goes and makes sure the ones
from A keep going up as well.
Search for the phrases "remote sequence" and "local sequence" in
RFC3261 sections 12.1 and 12.2 for more detail.
Early media in fact is exchange of sdp parameters through 183 session
progress message before getting the final 200 OK message. One typical
use of
it would be to play a music for the calling party by the proxy server
whenever it sees a call by a given party. So that means when the call
is in
progress (i.e. ringing at the called party), the calling party hears
the
music as decided by the proxy server as there is an early media
session
established between the proxy and the calling party. When the called
party
eventually answers the call, the early media session is closed and
the final
sdp exchange happens between the calling party and the called party
(as in
the 200 OK message), based on which media streams are opened.
Another use of early media would be to have a complete session
description
exchanged through 183 session progress message between the calling
and the
called party, and open the media stream immediately after getting the
200 OK

response (200 OK does not carry sdp normally in this case as its
already
been conveyed through the 183 session progress), this avoids
processing the
sdp after receiving 200 OK and thus establishes the call more
quickly.
No, early media is not necessary unless you have some specific
requirements
to do so.
Any 1xx message except 100 Trying is an end-to-end message. If the
INVITE forks, the client
will receive ALL 1xx > 100 sent by any receiving endpoint.
In particular, if the request forks to three places and they each
send 183s, the client is going to
receive three different 183s (and likely early media from all three
locations).
The relevant section of the spec is RFC3261 section 16.7 subsection 5
(see page 109).
As an aside - the 1xx messages have no built in recovery from
transport failure for unreliable transports (UDP).
There is an extension named 100rel (see RFC3262) that adds a
mechanism to ensure those provisional
messages get delivered if they are really important to the
application.
Note that a 405 (Method Not Allowed) is sent when the server
recognizes the request method, but that method is not allowed or
supported.
Some times you will get 501 not implemented due to codec support too,
and If
your invite sending double codec request in SDP it's also return 501(
If
terminating gateway not accept double codec request)
Sipp is a great free tool for bulk call generation.
Wireshark, ngrep, tcpdump for packet analysis.
As far as commercial products; Empirix Hammer and Ixia traffic
generators
are extremely powerful tools.

If the silence suppression attribute is not present in SDP, whats the

default behaviour? Would the absence mean ON or OFF for a certain
media
type?

there are many SIP testing tool are there in the open source (GPL
License), that can simulate SIP call flow with any number of
instance. I
have used miTester for SIP is the SIP testing tool to simulate a SIP
call flow for my testing. You could also try with miTester for SIP
downloading from source forge site. Here is the Link to download a
miTester for SIP
http://sourceforge.net/projects/mitesterforsip/files/
,you can download which OS you are using.
-An SDP session description consists of a session-level section
followed
by zero or more media-level sections. The session-level part starts
with
a "v=" line and continues to the first media-level section. Each
media-level section starts with an "m=" line and continues to the
next
media-level section or end of the whole session description. In
general,
session-level values are the default for all media unless overridden
by
an equivalent media-level value.
Some lines in each description are REQUIRED and some are OPTIONAL,
but
all MUST appear in exactly the order given here (the fixed order
greatly
enhances error detection and allows for a simple parser). OPTIONAL
items
are marked with a "*".
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below) z=*
(time
zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)

a=* (zero or more media attribute lines)

This SIP extension It is commonly used in IMS SIP signalling.
IMS UA inserts a P-Preferred-Identity header in any initial request
as as a preffered identity (P-Assesrted-Identity) within trusted IM
CN
subsystem.
It has some important aspects because the P-Asserted-Identity
decides about a set of services which are involved in further SIP
signalling
In a scenario when UAC sends initial INVITE without SDP body and UAS
responds with 200 OK (with SDP body) and now UAC sends ACK with nonmatching SDP body what will happen to session ??
At anytime if offer and answer is not successful than there is a
> possibility of the terminating the Session, which is also depend
upon the
> application logic. In this scenario, party B can trigger the BYE
> immediately after receiving invalid answer or session can be re
negotiated
> if party B wishes so.

I just wanted to know that in case to UA's are are talking with each
other
> using voip network and their registration times expire than what
will
> happen? Is call drops or UA will again sends a refresh Registration
request
> to the registrar?
UAs shall refresh registration before registration times out.
The registration request is sent to the UAS to identify UAC as part
of the
registered user in the SIP registrar server..It has timer inbuilt
within and
starts the counter after initial registration..It depends upon the UA
client what is the expiry counter set..During the call setup, the UA
client has to be registered with UAS to establish the call, if the
client is not registered you will get 403 forbidden. It wont
disconnect the call already been setup while the UAC was registered.
Is it good idea to send DTMF inband when using codecs like G.723?
Please advice.
It is not a good idea to send DTMF using lowbit rate codec.
Port 5060 is standard SIP TCP/UDP signalling port and port 5061 is
the
standard TLS SIP signalling port.

To setup an RTP session, an application defines a pair of destination

ports (an IP address with a pair of ports for RTP and RTCP). In a
multimedia session, each media stream is carried in a separate RTP
session, with its own RTCP packets reporting the reception quality
for
that session. For example, audio and video would travel in separate
RTP
session, enabling a receiver to select whether or not to receive a
particular stream.[10] An RTP port should be even and the RTCP port
should be the next higher port number if possible. Deviations from
this
rule can be signaled via RTP session descriptions in other protocols
(SDP). RTP and RTCP typically use unprivileged UDP ports (1024 to
65535),[11] but may use other transport protocols (most notably, SCTP
and DCCP) as well, as the protocol design is transport independent.
Voice over Internet Protocol (VoIP) systems most often use the
Session
Description Protocol (SDP)[12] to define RTP sessions and negotiate
the
parameters involved with other peers. The Real Time Streaming
Protocol
(RTSP) may be also be used to setup and control media session on
remote
media servers.

Hi,
In Your case UA1 should normally construct initial INVITE with SDP
offer containing this particular codec specification. Despite any
other non-media related reasons UA2 will reject INVITE with 488/606
(Not Acceptable Here) response in case the session description is not
acceptable or will accept session offer by sending a final 2xx
response with SDP answer containing the same codec
Specification. Provisional responses can also contain the same SDP
contents as final 2xx one.
> Hello All,
>
> UA1 can open channel only with one codec, so it need to negotiate
with > one codec
> I will take you to the example straight.
>
>
>
>
>

UA1
UA2
-----INVITE(Offer m =0 8 18)----------->
<-------200OK(Answer m=18 8)------------------INVITE(offer m=18)------------->
<-------200OK(Answer m=8 18)------------

> what should be the behaviour?? is there any standard stating the
> behaviour
>
> Hi,
Particular media and supported codecs are placed within media line
in SDP field within INVITE request. So if Your UA1 supports only one

codec it should placed it there.

The behaviour of the UA2 depends on the type of the offered stream
send by
the UA1.
If UA1 marked stream as receive only then m line in the response from
UA2
must contain at least on media format from the offer but it can also
indicate
additional format it supports not listed in the offer from UA1.
If stream is send only then UA2 must specify at least one codec from
those
received in the offer.
For send and receive streams m line in the answer from UA2 must
contain
at least one codec from the offer and can contain additional codec's
for informational purpose. Codecs can't be used because they weren't
present in the offer. There is additional behavior sepcified for
inactive
stream
but is very seldom case.

> If I understood well than I hope you are saying that the UA1 should
send
> Offer with 8 in media line,
>
> now suppose 200OK still has multiple codec (like 18 8) in answer ?
>
> So my question is that does it seem correct to send INVITE always.
>
> as it could be a unlimited exchange of messages
>
>
>
> Your opinion please
>
>
>
> Regards
> In Your case UA1 should normally construct initial INVITE with SDP
offer containing this particular codec specification. Despite any
other non-media
> related reasons UA2 will reject INVITE with 488/606 (Not Acceptable
Here) > response > in case the session description is not acceptable
or will accept session offer by sending a final 2xx response with
SDP answer containing the same codec specification.
Provisional responses can also contain the same SDP contents as final
2xx one.
Moving further
Answer to question one:
If I consider A,B,C are all UAC then no as because C would not be
ready to receive a response for the request it never generated and
would discard it.
Such a scenario can be seen where A receives a Request from C and
then generates the Invite towards B on behalf of C.
Answer to question two:

Call-id, to tag, from tag are session wise unique in the space and
time, they might not be used by other clients as they would be used
to identify dialog and session between agents.
Subject: [SIPForum-discussion] a question about re-invite
Hi all?
my understanding of a SIP re-invite is that it modifies the media
session. Is it capable of modifying the address of the send too? for
example? A is talking to B, can A send a re-invite to B with C's
address instead of its own address?
another example ?
A is talking to B? recorded as dialog1, C knows the
Information of the dialog1, can C sends a re-invite to B instead of
the dialog1, the dialog between C and B has the same Call-ID, fromtag, to-tag as dialog1?
SIP RE-Invite method is a mechanism of refreshing the session
primarily and not changing the session itself.
Moreover if suppose A and B are in session and somehow B wants A to
talk to C then the method refer would be used.
There are other implementations where a re-invite is sent to achieve
the same objective. This depends upon implementation largely.
The fact all such cases where re-invite is used in place of refer to
achieve similar functionalities there are serious resource
compromises to mitigate.

You need to install cygwin to run sipp in the windows environment and
sipp windows version.

Hello,
Why does the 2xx gets a unique handling for ACK messages? When client
transaction receives a 300-699 message, it creates an ACK message and
sends it out and informs TU about it. But if the client tx receives
2xx message, it cannot generate ACK message. It has to let the UAC
core to send the ACK message. Can someone explain why the difference?
Thanks,
Nick
The ACK for a non-2xx response is a hop-by-hop message and is easily
constructed from the request in the client transaction (i.e. it will
have the same Request-URI and Route headers as the INVITE request.
The ACK for a 2xx response is an in-dialog request that goes end-toend. It needs to be passed to the TU which has to update the dialog
state and populate the Request-URI with the remote target, and the
Route headers from the route-set. Also, if the INVITE did not contain
SDP, the TU will need to put SDP in the ACK.
Subject: [SIPForum-discussion] ACK handling in 2xx and non-2xx
messages

Transaction, dialog and session they are like one makes the other.
In a normal call flow
UAC
UAS
INVITE-------------------------->
Trying<-------------------------180<--------------------------200ok<------------------------ACK---------------------------->
BYE<---------------------------200OK------------------------->
-------------------------------------------------------------------Dialog:
-------------------------------------------------------------------When UAC sends INVITE to UAS, it contains From-tag and Call-ID in the
Message.
In response UAC receives 200 OK, and in 200 OK, To-tag will be
present.
* In SIP the From-tag, To-tag, Call-ID makes a Dialog.
So when there is a successful INVITE and its response, then a Dialog
is
established.
* A Dialog is a sequence of Transactions.
--------------------------------------------------------------------------------------------------------------------------------------Transaction
-------------------------------------------------------------------Every Request and its corresponding Responses makes a Transaction
Eg:
Transaction x: REGISTER and 200 OK
Transaction y: Bye and 200 OK
In case of INVITE, Transaction is as follows:
If UAC receives a successful response that is 200 OK for the INVITE
it
sends then the transaction includes ACK.
That is
Transaction is: INVITE---- 1xx responses -- 200 OK --- ACK
In case UAC receives a non Success response (anything other than 2xx)
transaction doesnot include ACK.
That is
Transaction is: INVITE --- a non 200 response
And ACK will be another transaction.
* In SIP Transaction is identified by the "CSeq number" in a Dialog
--------------------------------------------------------------------

-------------------------------------------------------------------Session
-------------------------------------------------------------------With every INVITE -- 200 OK -- ACK, a session is established, that is
the two clients have a session to exchange media. That's a session.
-------------------------------------------------------------------Hope it's clear.
I think NetHawk EAST can help you in this regard. It's very flexible
and easy-to-use tool which is very inteligent for load testing. For
more details please visit following link:
https://www.nethawk.fi/
>
> I want to know what error code the UAS must give to client for
calling to a
> switched off mobile phone?
>
If mobile phone is switched off, that means it is not registered and
no message will reach it. The domain node serving the unreachable
user,
implementing location service will answer any request targeted to
that user
with 480 temporarily Unavailable response.

 Most devices that send both 180 and 183 for one transaction send
them
in that order: first 180, then 183. There's no temporal coupling
between 180 and 183: they can occur in either order. (AFAIK.)
But beware if you use 183 with SDP, then start streaming RTP to the
calling endpoint, and then send a 180 to the UAC, you may get odd
results (such as overlapped ringback).
Yes, a Dialog ID is composed of Call ID, Remote Tag and Local tag.
When
an INVITE is sent we have the Local tag and Call ID.
The moment we get Remote Tag in 200 OK or 18x a DIALOG is
established. A
Remote tag in 18x is called Early Dialog.
Guess, only INVITE, REFER and SUBSCRIBE are the Dialog creating
methods
You do not appear to be offering the telephone-event type in the
media line of the INVITE message i.e. your m = line should read:
m=audio [auto_media_port] RTP/AVP 8 101
Hi All,

I am using following xml codes to send DTMF to my SIP application

and I am using the command line command "C:\Program
Files\Sipp_3.1>sipp 10.8.2.39 -sf test.xml -i 10.8.2.144 -mi
10.8.2.14
4 -s 3990 -l 1" to start SIPp. From the ethereal trace I can see DTMF
is sent to the destination IP address but my SIP application is not
detecting the DTMF.Is there anything I am missing please
suggest.Normally if I am calling from any phone dtmf is working fine
I am running SIPp in windows platform and using RFC2833 DTMF mode.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<scenario name="UAC with media">
<!-In client mode (sipp placing calls), the Call-ID MUST be
-->
<!-generated by sipp. To do so, use [call_id] keyword.
-->
<send retrans="500">
<![CDATA[
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:
[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=c=IN IP[local_ip_type] [local_ip]
t=0 0
m=audio [auto_media_port] RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11,16
]]>
</send>
<recv response="100" optional="true">
</recv>
<recv response="180" optional="true">
</recv>
<!-By adding rrs="true" (Record Route Sets), the route sets
-->
<!-are saved and used for following messages sent. Useful to test
-->
<!-against stateful SIP proxies/B2BUAs.
-->

<recv response="200" rtd="true" crlf="true">

</recv>
<!-Packet lost can be simulated in any send/recv message by
-->
<!-by adding the 'lost = "10"'. Value can be [1-100] percent.
-->
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:
[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:
[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>
</send>
<pause milliseconds="8000"/>
<!-Play an out of band DTMF '1'
-->
<nop>
<action>
<exec play_pcap_audio="pcap/dtmf_2833_1.pcap"/>
</action>
</nop>
<nop>
<action>
<exec play_pcap_audio="pcap/dtmf_2833_pound.pcap"/>
</action>
</nop>
<pause milliseconds="9000"/>
<!-The 'crlf' option inserts a blank line in the statistics report.
-->
<send retrans="500">
<![CDATA[
BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:
[local_port];branch=[branch]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:
[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 2 BYE
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
]]>

</send>
<recv response="200" crlf="true">
</recv>
<!-definition of the response time repartition table (unit is ms)
-->
<ResponseTime Repartition value="10, 20, 30, 40, 50, 100, 150, 200"/>
<!-definition of the call length repartition table (unit is ms)
-->
<CallLengthRepartition value="10, 50, 100, 500, 1000, 5000, 10000"/>
</scenario>
Rely on the user to hang up thereby sending a CANCEL to the far end
- interesting. So does your statement imply that on receiving a
provisional response, we must STOP TIMER B?
A related query - Any idea how the "session-expires" header works in
conjunction with this scenario? The client I use supports this header
and uses a default value of 1800 seconds. Does that mean the SIP
stack starts another timer for 30mins and hypothetically if the user
never ends the call, should this tear down the transaction? Or is
this timer only started for Confirmed Dialogs?

>Have a query regarding Timers.

>
>If a client sends an INVITE and receives a provisional response but
does NOT get a Final Response, is there a Timer that clears up the
transaction?
RFC3261 specifies Timer B as the INVITE Transaction Timeout Timer.
However in the state transition diagram, there is no mention of
whether Timer B is stopped, restarted on moving from the "CALLING"
state to the "PROCEEDING" state on receiving a 1xx message. These are
my specific queries:
Timer B is only relevant while transaction is in the initial
"calling" state.
It is used both for reliable and unreliable transports.
When transaction moves to "proceeding" state as it receives
a provisional response, it is completely up to UAC what to do then.
You can compare it to the situation when You call someone
and You hear never ending ringing in the phone.
Probably You will eventually give up and hang up.
The same thing happens here, UAC hang up by sending
a CANCEL which cancels the transaction.
>
>RFC3261 specifies Timer B as the INVITE Transaction Timeout Timer.
However in the state transition diagram, there is no mention of
whether Timer B is stopped,restarted on moving from the "CALLING"
state to the "PROCEEDING" state on receiving a 1xx message. These are
my specific queries:
>
>
1. If while in "PROCEEDING" state no final response is
received, what happens?

>
2. Is it implied that Timer B is only stopped/canceled on
receiving a final response?
>
3. What happens when Timer B fires?
> Should the client send a CANCEL or just kill the transaction?Thanks
for any inputs in this regard.
>

SIP defines two types of responses, provisional and final.

Final responses convey the result of the request processing, and are
sent reliably.
Provisional responses provide information on the progress of the
request
processing, but are not sent reliably in RFC 3261.
Both UAC & UAS will response with CANCEL after 32 Sec when there is
no
additional provisional or final response.
The PRACK should provide the reliable answer to the un-reliable
response.
This Session-Expires timer will be started only for the confirmed
dialogs.
In your case still the call is not established and it is in ringing
state..so u can't rely on the session expires header.
*Base SIP (defined by RFC 3261 and updated by 3265, 3853, 4320, 4916
and
5393)
doesn't make use of Timer B except when transaction is in the initial
"calling" state.
You can apply such behaviour that Timer B is still active in
"proceeding"
state and fires
which causes a CANCEL to be sent but this would be an implementation
specific behaviour.
Session timer mechanism is a keep alive mechanism for SIP Session.
It is arranged through a periodic session refresh by re-INVITE or
UPDATE
requests.
When initial INVITE transaction is in the "proceeding" state there is
no
session yet established
and You can not send another INVITE as long as You don't receive
response to
the currently processed.
Beside that session timer mechanism is targeted rather for proxies
then UAs.
User agents can determine state of the session through local means
while
Proxy don't.
Session timer gives them a way to explicitly determine if the ongoing
session can be considered finished.
Kind regards,

- Tomasz Zieleniewski

- If UAC supports PRACK than it should add supported header

containing 100rel.

A
PRACK
is generated by a UAC when a provisional response has been
received containing a
RSeq
reliable sequence number and a

Supported:100rel
header. The
PRACK
echoes the number in the RSeq
and the
CSeq
of the response in a
RAck
header
>
- If UAC supports PRACK and not including 100rel means that it
supports but not interested to handle PRACK. and server should assume
that uac is not supporting this extension. RFC 3262 says
>
"If the request did not include either a Supported or Require
header field indicating this feature, the UAS MUST NOT send the
provisional response reliably."
>
>
even if UAC receives Rseq from sip server, it means that server
is not behaving as per RFC recommendations. so you are free to
support sip server on your risk :-) and you can send a PRACK but is
not recommended. I think better way is to send CANCEL and send a new
request with supported header containing 100rel.
>
>
- If UAC includes supported header containing 100rel means that
it supports this extension and provides flexibility to uas. UAS may
send 1xx with RSeq or may not. Depends upon sip server interests. :-)
>
>
- If UAC includes require header containing 100rel means that it
is forcing to
> > plz go through the two state ment ......n i think definitely u
wil get ur ans................

The problem is , if UAC receives no Rseq (of course no

"require:100rel" in response), it means the UAS doesnt want PRACK in
place at all, so UAC won't send PRACK but wait until non-1xx response
arrives. So if all the entities behave correctly, the scenary you've
given is impossible.

Timer B is used for transaction. or we can say it controls

transaction time out. while timer A controls the request retransmission. and which is not required in case of reliable
transport. It may possible that server is eating sip request and not
responding :-). In that case B timer timeout and uac transaction
comes in terminated state and uac can start required clean up at
their end.

Not only timer A is used for re-transmission but there are some
other simlar timer are used for un-reliable delivery like D, E etc.
is that make sense ?

for unreliable network timer A is set to fire as this timer is used

for Invite transaction retransmission interval
for UDP only and UDP is non trusted type of protocol for transport so
it necessary to fire in that case .
But if its using any trusted protocol then timer B is used INVITE
transaction timeout timer which is 64*T1(T1 is 500ms)

Transaction Layer Errors

In some cases, the response returned by the transaction layer will

not be a SIP message, but rather a transaction layer error. When
a

timeout error is received from the transaction layer, it MUST be

treated as if a 408 (Request Timeout) status code has been
received.
If a fatal transport error is reported by the transport layer
(generally, due to fatal ICMP errors in UDP or connection failures
in
TCP), the condition MUST be treated as a 503 (Service Unavailable)
status code.

this is from RFC 3261 and RFC 3204

The Content-Disposition header field describes how the message body
is to be interpreted by the UAC or UAS ..The values for content
disposion is given below
*session* - body part describes a session, for either calls or early
(pre-call) media
*render*- the body part should be displayed or otherwise rendered to
the
user
*icon* - the body part contains an image suitable as an iconic
representation of the caller or callee that could be rendered
informationally by a user agent when a message has been received, or
persistently while a dialog takes place
*alert*- the body part contains information, such as an audio clip,
that
should be rendered by the user agent in an attempt to alert the user
to the
receipt of a request
if the Content-Disposition header field is missing, the server SHOULD
assume
bodies of Content-Type application/sdp are the disposition "session",
while

other content types are "render".

other fieled handling-param is associated with Content-Disposition
handling-param, describes how the UAS should react if it receives a
message
body whose content type or disposition type it does not understand
If the handling-param has the value "optional", the UAS MUST ignore
the
message body; if it has the value "required", the UAS MUST return 415
(Unsupported Media Type). If the handling parameter is missing, the
value
"required" is to be assumed.
regards

Hi,
1. Yes, BYE messages are retransmitted given that unreliable
transport(UDP)
is being used
2. again yes CANCEL messages are retransmitted given that unreliable
transport(UDP) is being used

I came across to this situation where we receive inbound call the

codec
preference set on the SIP INVITE is 711 first and 729 second (m=audio
50000 RTP/AVP 0 18 100) when our softswitch reply back with a 200 OK
with SDP we set the preference as 729 first and 711 second (m=audio
3006
RTP/AVP 18 0 100). Instead of cutting the media over to 729 (means
select this as a codec because the 200 OK has 729 set as preference
and
initial INVITE has both options) The peering partner sends a REINVITE
with 729 as the only option (a=rtpmap:18 G729/8000).

My question is this legal in SIP. Is codec can be negotiated that way

as
well. I thought that carrier should negotiate the codec base on the
preference my Softswitch set on 200 OK

The flow is valid and usually what the offerer do also. Check section
10.2 of rfc 3264 and you will get your answer. When the answer
carries a
list of codec, the original offerer would "usually" send a new offer

with a single codec to negotiate down to one. This is usually done

when
the UAS wants to include all in the answer and let offerer decide
what
it wants/prefers. The preference in the 200OK doesnt drive the codec
selection but what comes in INVITE or offer does. ( in your case )
Answer is the preference local to answerer but offerer picks the
preference.
In SIP, the offerer preference takes precedence. In H323 world, the
so
called answerer preference takes precedence. Its the recommended way.
In
your case if you include all codecs, it would mean your switch should
be
ready to listen on those media streams anytime in the session. Not
sure
if thats what your intention is? So if you want to use your preferred
one, I would say only include one media stream for simplicity in the
answer.
>From spec something about preference.
Although the answerer MAY list the formats in their desired order of
preference, it is RECOMMENDED that unless there is a specific
reason,
the answerer list formats in the same relative order they were
present in the offer. In other words, if a stream in the offer
lists
audio codecs 8, 22 and 48, in that order, and the answerer only
supports codecs 8 and 48, it is RECOMMENDED that, if the answerer
has

in

no reason to change it, the ordering of codecs in the answer be 8,

48, and not 48, 8. This helps assure that the same codec is used
both directions.

Transaction, dialog and session they are like one makes the other. No
dialog without transaction and no session without a dialog. But there
can be transactions without dialogs and dialogs without sessions.
Transaction: every request and response pair would make a
transaction.
[Please note that when I say that I mean a request and a successful
response for that request. In case there is a failure response for a
particular request then the transaction is not over till it receives
message which can clearly tell that the UAC to kill the transaction]
Basically transaction is a way of keeping a track of UAS and the UAC
interactions done independently.
Register--->
<-------200 OK

is a complete transaction.

Invite --->
<------3xx,4xx,5xx
ACK------> is also a transaction.
[3261] Dialog: Dialog can only be formed by the INVITE request when
there is a non-failure [101-199]/ [200] response for it.
Further RFC3265 also explains how subscribe notify pair can also form
a
dialog. I think it is never wrong to consider a dialog as special
transaction which merely matures as a dialog. Dialog can have states.
Invite----->
<--------100 {optional}
<--------200
Ack ----->
is a full dialog [but it has two transactions]
Sessions: we use sip just for signalling. It is not a complete
protocol
within itself to serve any purpose. So sip itself works with other
protocols like rtp and sdp to inform the two ends about the type of
conversation that can be possible. So plainly whenever a dialog
(couple
of transactions) or a sequence of message exchange are capable of
educating the other end about the required information regarding the
intended conversation the dialog can support a session where the
protocols like RTP or SRTP would be used to facilitate the service
for
which all the signaling was done.
So we can easily say (in a crude way) when a sip signaling
facilitates
the two ends to exchange information by using some other protocol
(whose
information was carried by SIP signals) we have a session.
A session would always have some capabilities which would be conveyed
by
the dialog which made it possible.
So far I have always seen Sessions in dialogs initiated by the INVITE
method only and I think it can be only that way. [Anyone else in the
forum if has some other experiences please put in your views]
Further RFC3261 is equipped with definitions of all these but what

confuses me is the place where it says: "A dialog is a peer-to-peer

SIP
relationship between two UAs that persists for some time"
As I have never been able to understand how much this some time
should
be.

Below is the bit explanation of dialog, transaction & session.

Dailog:
*Dialog* is a peer-to-peer relationship between two user agents. It
represents a context that facilitates the sequencing of messages
between the
user agents and proper routing of requests between both of them.

Transaction:
Transaction is a request sent by a client transaction (using the
transport
layer) to a server transaction, along with all responses to that
request
sent from the server transaction back to the client. Any task that a
user
agent client (UAC) accomplishes takes place using a series of
transactions.

Session:
A *session* refers to all
make to
a server in the course of
application. Sessions are
the
application. As a result,
session and has access to

the connections that a single client might

viewing any pages associated with a given
specific to both the individual user and
every user of an application has a separate
a separate set of session variables.

Hi Gopa,
I depends on how the UAS configured policy/behaviour when handling
misbehaving UAC that attempts to register at lower interval even
after
423 response is sent. It is implementation dependent as mentioned
previously by Abhishek. For example, I configured my sip server to
response with 488 whenever UAC misbehave after 423. Any client-server
based is subjected to DOS attacks, and SIP-VoIP is not spared from
this.
Gopalarathnam Sambasivan wrote:
> Hi Abhishek, All,
> Thanks, My query is mainly for protecting the UAS from frequent
> re-register bursts as RFC does not explicitly

> state a method of handling this scenario case2. RFC just states
that
> it is the resposibility of UAC to refresh the
> bindings and it has to do so before the expires of the earlier
> register (not when (duration)??).
>
> Please let me know a mechanism for protecting UAS from re-register
bursts.
> I could not find a solution compliant with RFC.
>
> Please do note that UAC need not be a SIP phone but a MGC which
> serves several GWs (subscrs) using SIP.
> consider every 1 min re- register (2hr expires) coming from UAC to
UAS
> (valid according 2 RFC) for all subscrs not in
> call. Re-registers need to be sent before expiry to have bindings
and
> have a continuos service, which is a must from
> UAC (MGC) perspective.
>
> Case 2 is a client side error and correct possible error codes can
be
> (But these does not have the retry-after header)
>
>
400 Bad Request
>
406 Not Acceptable
>
423 Interval Too Brief
>
488 Not Acceptable Here
>
> 20.33 Retry-After
>
>
The Retry-After header field can be used with a 500 (Server
Internal
>
Error) or 503 (Service Unavailable) response to indicate how
long the
>
service is expected to be unavailable to the requesting client
and
>
with a 404 (Not Found), 413 (Request Entity Too Large), 480
>
(Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603
>
(Decline) response to indicate when the called party anticipates
>
being available again. The value of this field is a positive
integer
>
number of seconds (in decimal) after the time of the response.
>
>
An optional comment can be used to indicate additional
information
>
about the time of callback. An optional "duration" parameter
>
indicates how long the called party will be reachable starting
at the
>
initial time of availability. If no duration parameter is
given, the
>
service is assumed to be available indefinitely.
>
>
Examples:
>
>
Retry-After: 18000;duration=3600
>
Retry-After: 120 (I'm in a meeting)
>
> Case1.
>
> UAC sends a REGISTER with expires=1800 to UAS which has say
>
> min-expires=3600.

>
[Abhishek] I think Min-Expires: 3600 is too large value,
anyways RFC
>
does not disallow this value so it is OK.
>
> UAS rejects the REGISTER with 423 (Interval Too Brief) with
>
> min-expires=3600 - OK.
>
> A retry of register with min-expires accepted by the server
is
>
> successful.
>
>
>
> Case2.
>
> UAC sends a REGISTER with expires=7600 to UAS which has say
>
> min-expires=3600.
>
> There is no subscribe notify for subsequent registrations and
hence
>
> REGISTER is sent after
>
> random time interval between 1 and expires.
>
>
>
> Say there is re- REGISTER s with expires=7600, coming every x
secs
>
> which is less than the
>
> configured min-expires in the registrar.
>
>
>
> Question 1.
>
> Can the server reject these frequent re-registers within
>
registration
>
> expiry with 423 response?
>
> The min-expires seems to be available for the server to avoid
>
flooding
>
> of incoming registers.
>
> But according to RFC3261 sec 10.3 it cannot be done. so what
can be
>
> done?
>
> what is expected from perspective of UAS testing?
>
[Abhishek] No, registrar cannot reject REGISTER with 423 for
frequent
>
registrations. Registrar can send 423 only if registration
expiry is
>
less than its configured value.
>
>
>
> Question 2.
>
> From the perspective of UAC testing, can it be ensured that
Re>
> REGISTERS are sent only after min-expiry - 3600 on safer side
and
>
> before Expires - so that UAS will always treat the REGISTER
without
>
> overload?
>
[Abhishek] Unfortunately it is implementation dependent.
Usually sip
>
phone sends registration refresh slightly before session expiry
(or on
>
session expiry).
>
>
>
> Thanks & Best Regards,
>
> Gopalarathnam.
>
>
>
>
>
> REGISTER which is repeated after every x secs < configured
>
> min-expires:
>
> ===========================================================

>
> REGISTER sip:registrar.biloxi.com
<http://registrar.biloxi.com>
>
SIP/2.0
>
>
Via: SIP/2.0/UDP bobspc.biloxi.com:5060
>
<http://bobspc.biloxi.com:5060>;branch=z9hG4bKnashds7
>
>
Max-Forwards: 70
>
>
To: Bob <sip:bob at biloxi.com <mailto:sip:bob at
biloxi.com>>
>
>
From: Bob < sip:bob at biloxi.com
>
<mailto:sip:bob at biloxi.com>>;tag=456248
>
>
Call-ID: 843817637684230 at 998sdasdh09
>
>
CSeq: 1826 REGISTER
>
>
Contact: <sip:bob at 192.0.2.4 <mailto:sip:bob at
192.0.2.4>>
>
>
Expires: 7200
>
>
Content-Length: 0
>
>
>
> Part from RFC3261 sec 10.3 Processing REGISTER Requests:
>
> ==============================================
>
>
The registrar MAY choose an expiration less than the
>
> requested
>
>
expiration interval. If and only if the requested
>
expiration
>
>
interval is greater than zero AND smaller than one
hour AND
>
>
less than a registrar-configured minimum, the
registrar
>
MAY
>
>
reject the registration with a response of 423
>
(Interval Too
>
>
Brief). This response MUST contain a Min-Expires
header
>
> field
>
>
that states the minimum expiration interval the
>
registrar is
>
>
willing to honor. It then skips the remaining
steps.
>
>
>
>
>
>
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

Differences b/w Allow, Supported, Require & Options

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?
>>
>> 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.

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.

405 vs 501
> <<21.5.2 501 Not Implemented
>
>
The server does not support the functionality required to
fulfill
request. This is the appropriate
response when a UAS does not
>
recognize the request method and is not capable of supporting it
for
>
any user. (Proxies forward all requests regardless of method.)
>
>
Note that a 405 (Method Not Allowed) is sent when the server
>
recognizes the request method, but that method is not allowed or
>
supported.>>
It does appear that that last sentence isn't written quite corectly.
Clearly, the intention is that 501 means "this user agent does not
implement that method" and 405 meand "this user agent implements that
method, but this request is not alloed".
A better phrasing of the last sentence would be

something like:
>
>
>

Note that a 405 (Method Not Allowed) is sent when the server
recognizes the request method, but that method is not allowed or
supported in this request.>>

405 Method Not Allowed

This response indicates that the server or user agent has received
and understood a request but is not willing to fulfill the request.
An example might be a REGISTER request sent to a user agent. An Allow
header field (Section 6.4.1)
must be present to inform the UAC what methods are acceptable. This
is different
from the case of an unknown method, in which a 501 Not Implemented
response is returned. Note that a proxy will forward request types it
does not understand unless the request is targeted to the proxy
server (i.e., the
Request-URI is the URI of the proxy server).
Query about 415 and 488 responses:
To elaborate further, 415 is not related to just the Content-Type
header, RFC 3261 clearly mentions that:
"If there are any bodies whose type (indicated by the Content-Type),
language (indicated by the Content-Language) or encoding (indicated
by
the Content-Encoding) are not understood, and that body part is not
optional (as indicated by the Content-Disposition header field), the
UAS MUST reject the request with a 415(Unsupported Media Type)
response."
Similarly, for the 488 response
"means that the user wishes to communicate, but cannot adequately
support the session described."
It may not necessarily because the user *does not understand/
support*
but also due to the fact that the user is currently unable to proceed
with this call based on the offered parameters. A typical example is
that many fax machines do not allow simultaneous SIP-T.38 fax calls
so
the 2nd INVITE is typically rejected with a 488.

If we get application in m line and if we don't support that

application can we reject the same with port zero...
Offer:
m= Application 50000 udp TBCP
a= fmtp:TBCP queuing=1; tb_priority=2; timestamp=1
Answer:
m= Application 0 udp TBCP

a= fmtp:TBCP queuing=1; tb_priority=2; timestamp=1

is the above offer/answer is correct....?
Yes you can reject the same with port zero and the offer/answer you
mentioned is correct

Andreas,

My thouhts are if you include the a=fmtp

line in the SDP as
you
have illustrated below then the receiver knows you are capable of
recieving those DTMF and Tone events - but if the Answerer does not
return
the a=fmtp SDP line in the response with it's supported events then
the
Offerer will not be able to assume to use them. Comments inline >To show what kind of events values (RFC2833 DTMF) a UA can receive
it
"may"
>send a attribute a=fmtp:101 0-15,66,70.
>As I understand, if a AU receives this information from the remote
side
in
>an invite, this UA doesn't have to add a fmtp in the 200 OK if it
only
can
>receive 0-15 (since this is mandatory)? Is this a valid scenario:
>>From A in invite:
>a=fmtp:101 0-15,66,70
>>From B in 200 OK:
>No fmtp attribute.
Wayne - I am thinking in this scenario B would be able to send the 015
DTMF events and 66, 70 Tone events to A but A should not send them to
B as
B has not advertised support for it ?. If B is prepared to accept
those or
a subset it should include it in the response.
>In the call above, A and B will send dtmf using rfc2833 for 1-15?
>If AU initiate a call and wants to use rfc2833 dtmf for format 1-15,
it
>should be enough to have:
>m=audio 7000 RTP/AVP 0 8 101
>a=rtpmap:0 PCMU/8000
>a=rtpmap:8 PCMA/8000
>a=rtpmap:101 telephone-event/8000
>Sending this media description above will indicate for the remote
side
that
>I want to use out of band dtmf according to rfc2833 and I can
receive
dtmf

>events 0 to 15? This means it is no need for me to add fmtp if I

only
>support events 1-15?
Wayne - yes, the above is my understanding as well.
>