Wednesday, 29 April 2015

Where
do we experience Internet Telephony or/and SIP in our daily lives?We
use these technologies in many different ways. Sometimes we are not
even aware of using it... For instance one may use a calling card
number to make a phone call, which routes the call via VoIP gateways.
Instant Messaging tools use these technologies. Some people use IP
phones (e.g. Vonage) at home. Some use PTT phones which utilize VoIP
technology. There are many more areas/ways where we use these
technologies. The key areas are illustrated in our eLearning.SIP
is a VoIP protocol – so does it carry voice packets?For
the most part SIP does signaling. Voice is carried by other real time
protocols such as RTP. There are some implementations however where
SIP is used to carry the media itself. For example SIP can carry the
media (normally text) of an Instant Message in the payload of a SIP
message (request) called MESSAGE...Do
I always need to use a proxy server?First of
all it is not you, it is rather your SIP phone that may need to use
it... Second, the answer is NO. SIP phone needs to use SIP proxy
server only when it does not know the IP address (or host name) of
the destination or if the policy of the operator (ISP) mandates it.
So for example say you like to establish a white board session with a
colleague of yours, using SIP based client such as Net Meeting. Now
if she provides you the IP address of her machine, you can contact
her machine directly.
Is
the Microsoft messenger the only SIP based messenger tool?Definitely
not.I
want to build a SIP phone - is SIP all what it takes?Well,
not quite. If you don't equip it with RTP stack and couple of
vocoders it might be useless. It depends of course on the use you
intend for it.

Some
services, like repetitive dialing, station speed dialing, last number
redial, and distinctive ringing, are implemented purely in the end
system and require no support from the signaling protocol. The
Telecommunications Industry Association (TIA) is working on a
recommendation
for business PBX-style services and other Internet phone
requirements.

How
does SIP support caller ID?

Caller-ID
is provided by the From SIP header containing the caller's
name and "number". The number would most likely be placed
in the user field of a SIP URL or appear in a tel: URL. Since the
callee generally does not know or trust the callee's server, only
cryptographic signatures can be used to ensure that the information
is valid. For example, the outgoing proxy might be operated by an
ISP, enterprise or phone company and sign for the identity of the
caller, using the signedby parameter, with the identity of the
company verified by a public key certificate similar to those used by
web sites.

Should
SIP be used to join a conference from a web page?

It is possible to embed a
SIP URL in a web page, including a session description. Clicking on
that link triggers an invitation for the conference listed to the
address contained in the URL. Unfortunately, the current standard
browsers (Netscape and Internet Explorer) make it difficult or
impossible to add support for another URL type. Until SIP URIs are
implemented in standard browsers, data:
URLs can be used to implement similar functionality, albeit less
elegantly. If it is desired that following the link directly adds the
user to an existing conference, e.g., for a conference "TV
guide"-style directory, the data:
URL is more appropriate.
Can a
SIP-initiated session have zero or one participants?SIP-initiated sessions can
have no or just one participant. Examples of a session with no
participants include an invitation to a multicast group with no
members (beyond the invited party). Also, SDP sessions can start at a
future time relative to the invitation.How
do I charge/bill for Internet telephony using SIP?This depends on whether you
plan to charge for SIP services like directory look-ups, call
processing or mobility, for gateway services to the PSTN, or for
carrying media data:
SIP services -

The
Authorization
header can be used to indicate a customer identity that associates a
SIP request with a billable entity.

Examples
of possibly chargeable SIP services include:

Directory
services such as SIP proxy/redirect lookups;

Customer
profile management;

SIP
server operations can be charged based on server logs or, for
real-time billing, via AAA.

Media services - Media services include
retrieving and storing voice mail, as well as transcoding of media
streams. They are not initiated by SIP, but, for example, via RTSP.Gateway services - Similar to SIP services.
Care has to be taken to stop billing when (say) RTP voice data is no
longer flowing through the gateway. The gateway will generate call
detail records (CDRs) either directly or through RADIUS.
Transport (network
services) -

It
seems unlikely that voice calls carried over a best-effort service
will generate per-minute charges. When reserving bandwidth or
guaranteeing other quality-of-service parameters, the resource
reservation protocol or differentiated services are the appropriate
mechanism for including charging. These reservation protocols will
likely be used in applications that are not initiated by SIP, for
example, audio/video on demand or VPNs. Actual accounting records may
be generated by AAA protocols (e.g., by policy enforcement points
(PEP) or policy decision points (PDP)) or log files.

Under
some circumstances, a SIP proxy server may be useful to initiate such
reservations or differentiated services treatment on behalf of a
call, since it may be easier to authenticate the SIP request than the
lower-layer reservation request or the end system may not be capable
of making reservations or marking packets. In those cases, the SIP
proxy would initiate a resource reservation and "charge back"
the caller identified by the SIP request.

How
do prepaid calling cards work in SIP?

Note
that, in general, prepaid calling cards only make sense in an IP
network if there is a special-purpose VoIP internet, calls traverse a
IP-to-PSTN gateway or VoIP packets receive special treatment. The SIP
requests are forced to traverse a stateful proxy, which controls the
Internet telephony gateway, router QOS function or firewall,
depending on the architecture. When the time is used up, the proxy or
gateway issues a BYE
request to both parties, using the existing call ID. It also disables
the gateway connection, turns of any special QOS treatment for the
RTP packets or closes the firewall for that stream. This requires no
additions to either caller or callee. Relying on SIP BYE
itself only suffices the end systems can be trusted by the network
provider not to keep sending packets.

Does
SIP carry DTMF? There are at least two
options for carrying DTMF and similar signals in a VoIP network using
SIP. First, DTMF can be transported as an RTP payload (RFC
2833). This has the advantage that it provides accurate timing
and alignment with the speech RTP packets. Also, media gateways are
the most likely to detect and generate tones, so that making it part
of the media stream is appropriate. However, under some
circumstances, it may be necessary for signaling entities to know
about DTMF signals. Currently, there is no standardized solution
within SIP, but it has been proposed to carry DTMF information in SIP
INFO messages, either encoded as simple text or using the RFC 2833
format. The latter is more complex, but offers duration and timing
information.

---
SIP Protocol Operation---

What
does the [H14.17] in RFC 3261 stand for?This is explained in
Section 3 of RFC 2543. It refers to the section number in the
HTTP/1.1 specification.Do
callers need to know the location of the location server?

The
caller doesn't interact with the location server directly. A redirect
or proxy server asks the location server (which may be co-resident
with the SIP server or not) for "advice". The location
server is just a logical abstraction to indicate where the SIP server
gets its information from. The protocol between SIP server and
location server is beyond the scope of SIP. Examples of location
servers include

finger;

LDAP/X.500;

whois,
whois++;

ph
and other local directories;

shared
file systems with registration on login;

local
SQL databases reached through TCP.

Also,
callers don't register with the location server.

Which
parts of SIP are case-sensitive or case-insensitive?

Method

CS

Header
field name

CI

Hide

CI

Accept-Encoding

CI

Accept

CI

Accept-Language

CI

Encoding
name (PCMU, L16, etc.)

CI

rfc1123-date

CS

What
is the difference between a call leg and a call id?

A
call leg refers to the one-to-one signaling relationship between two
user agents (UAs). The Call-ID
is an identifier, carried in the SIP messages, that refers to the
call. A call is a collection of call legs. A UAC starts by sending an
INVITE;
because of forking, it may receive multiple 200 OKs from different
UAs. Each corresponds to a different call leg within the same call.
Call is thus a grouping of call legs. In the call control spec,
additional call legs are created through the Also
header.

Call
legs refer to end-to-end connections between user agents, rather than
any relationship with proxies. Within a call leg, there are numerous
transactions in both directions.

The
request URI is not used in call leg identification.

The
To
and From
field relate to local and remote in the following way. When Alice
sends a request on a call leg to Bob, the From
field contains the local address (Alice), and the To
field the remote address (Bob). When a request is received by Bob,
the To
field is matched to Bob's local address, and the From
field to the remote address (Alice).

The
CSeq
spaces in the two directions of a call leg are independent. Within a
single direction, the sequence number is incremented for each
transaction.

What
is the difference between tag and branch-id?

Branch IDs allow proxies to
match responses to forked requests. Without them, a proxy wouldn't be
able to tell which branch a response corresponds to. Tags, in To
headers, are of no help here since they are not known until responses
arrive. Tags are used by the UAC to distinguish multiple final
responses from different UAS.
A UAS has no reliable way
of determining if the request has been forked or not. Thus, to be
safe it needs to add a tag. Proxies only insert tags into the final
responses they generate themselves; they never insert tags into
requests or responses they forward.
Since a request can be
forked several times on its way to UAS, a single "tag" (or
whatever you like to call it) added to the request by one of the
proxies is not sufficient for the next forking proxy along the chain
to match responses on its own branches; every proxy that forked the
request would need to add its own unique IDs to the branches it
created. This is precisely what's being achieved by the branch
parameter in the Via
header. (Igor Slepchin)
How
can one recognize a retransmitted request?

header

retransmitted

duplicate

matching
response

From

same

same

same

To

same

same

same,
but tag may have been added

Call-ID

same

same

same

request
URI

same

same

same

CSeq

same

same

same

Via

-

-

must
be local host; check for branch parameter to identify which branch

Looped
request are recognized by one or more of the following:

The
server finds itself in the request's Via
list, including
any branch parameter.
(The server should compute the branch parameter so that it depends
on the request URI.)

The
server is about to proxy the request to one of the hosts listed in
the Via
list. The same

The
Max-Forward
count is decremented to zero.

The
Expires
time has elapsed.

How
does a caller find its local registrar?The local registrar is
either manually configured or discovered via DHCP (RFC
3361) . Another more theoretical option is: the SIP client issues
a multicast registration request to the sip.mcast.net
standard
multicast address, which all registrars (are supposed to) listen to
(but in practice not all do).Is
the domain of the request-URI and the To header always the same?The Request-URI names the
destination of the registration request, i.e., the domain of the
registrar. The user name must be empty. Generally, the domains in the
Request-URI and the To header field have the same value; however, it
is possible to register as a "visitor", while maintaining
one's name. For example, a traveler sip:alice@acme.com (To)
might register under the Request-URI sip:atlanta.hiayh.org with the
former as the To
header field and the latter as the Request-URI. Note, however, that
requests for a user at acme.com are not likely to arrive at the
atlanta.hiayh.org server; special purpose routing logic will
generally need to be established in order for requests for
alice@acme.com to go to the atlanta.hiayh.org server. In the vast
majority of cases, the domains in the request URI and To field will
match. The REGISTER
request is no longer forwarded once it has reached the server whose
authoritative domain is the one listed in the Request-URI.

Are
ACK requests retransmitted?

Not
per say. An ACK
is sent when a response retransmission is received. Reliability is
achieved because the response is retransmitted until an ACK
arrives, and the ACK
is retransmitted on response retransmissions. ACK
is only used for INVITE.

How
are BYE requests routed?

Since
a Contact
header MUST be present in INVITE
and 200, the BYE
will go directly to the user agent if there is no Record-Route
header. If there is a Record-Route,
it will traverse the list of proxies indicated there.

If
the caller decides to send a BYE
before receiving a 200 from the callee, the BYE
is being handled by the proxies just as the corresponding INVITE
was handled, i.e., it may be forked.

Can
I CANCEL requests other than the first INVITE?

Yes,
any request can be cancelled before it has been executed by the UAS.
However, it is likely that this will only make sense in practice for
the initial INVITE
and subsequent "re"INVITE
(as for INVITE it may take longer time to get a final response than
for non-dialog-establishing type of requests, such as OPTIONS or
INFO). Btw, In
the latter case ("re"INVITE),
the call remains, just any changes requests are cancelled.

What
is the relationship between the From, Contact, Via and
Record-Route/Route headers?All these headers determine
how requests and responses are routed in a network of SIP proxy
servers. Roughly, the distinction is:
From:Used for subsequent
requests if there is no Contact
or Record-Route
header. E.g., if Alice makes a call with From: Alice
<alice@example.org> to Bob, an INVITE
request from Bob to Alice would use alice@example.org as the To
header and Request-URI.
Contact:Determines the destination
placed in the Request-URI for subsequent requests and can be used to
bypass proxies not enumerated in a Record-Route header. Also used in
responses by redirect servers and in REGISTER
requests and responses.
Record-Route/Route:The Record-Route header is
inserted into requests by proxies that want to be in the path of
subsequent requests for the same call-id. It is then used by the user
agent to route subsequent requests. The mechanism is similar to a
source-route, copying the Record-Route information into a set of
Route headers. The Request-URI is set to the first Route header.
Via:Via headers are inserted by
servers into requests to detect loops and to allow responses to find
their way back to the client. They have no influence on the routing
of future requests (or responses).
Generally, in short,
requests should be sent to Route
if present, Contact
if there is no Route,
From
if there is no Contact.
How
are URLs compared?

Two
SIP URLs are compared for equality according to the following rules:

the
display name is ignored;

tags
must match;

user,
password, host, port and parameters of the URI must match. If a
component is omitted, it matches based on its default value.

string
comparisons are case-insensitive;

Characters
other than those in the "reserved" and "unsafe"
sets (see RFC 2396) are equivalent to their ""%"
HEX HEX" encoding.

An
IP address that is the result of a DNS lookup on a hostname does
not match that hostname.

What's
the difference between the request URIs tel:+12125551212 and
sip:12125551212@gw.com?Non-SIP URLs, such as
tel:+12125551212 for a telephone number, may be used as request URIs
in SIP INVITE
requests. This only makes sense if all outbound calls are handled by
a proxy server. In the case of a tel: URL, the proxy server would
then translate the request URL to a SIP URL of a gateway server, if
it is not handling the gateway duty itself. The proxy server might
use the Gateway Location Protocol (GLP) to find the appropriate
next-hop SIP server. The To
header may always be a tel: URL even if the Request-URI is a SIP URL,
although that breaks with the common practice that Request-URI and To
start out the same.Does
SIP do admission control?Since this offers no real
security (calls could always bypass a server), admission control is
not supported by SIP. If an "outbound proxy" is used for
outgoing calls, that proxy may control the firewall and thus restrict
outgoing calls.Does
SIP administer bandwidth?No, that is the role of a
resource reservation protocol. There is no reason to assume that any
Internet telephony signaling server (such as a proxy) would know the
available bandwidth in real networks. Having such a central server
would not scale. Administering bandwidth separately for each
application is also likely to be difficult and inefficient.
There is a proposal for an
SDP extension (RFC
3312) that allows SIP INVITE requests and responses to indicate
that resource reservation must succeed before the callee is alerted
(was initiated by 3GPP as part of IMS).
Do I
always need a proxy or redirect server?No, two SIP endpoints can
contact each other directly.How
does a caller find its proxy server?Calls typically proceed
directly to the callee's domain. For example, when calling
alice@example.com the INVITE
request would be sent to the SIP server for the domain example.com
found via DNS.
If a "local"
(outbound) proxy is needed for outgoing calls, it currently needs to
be manually configured, similar to the configuration of web proxies
in browsers. Extensions to (for example) use a REGISTER
response or DHCP are under discussion.What's
the difference between a stateless and a stateful proxy server?Stateless proxies forget
about the SIP request once it has been forwarded. Stateful proxies
remember the request after it has been forwarded, so they can
associate the response with some internal state. In other words,
stateful proxies maintain transaction
state. Stateful
implies transaction state, not
call state.Stateless proxies scale
very well, and can be very fast. They are good for network cores.
Stateful proxies can do more (they can fork, for example, see the
next question) and can provide services stateless ones can't (call
forward busy, for example). They don't scale as much as stateless
ones. An administrator gets to decide which to use. These are also
logical entities; a physical proxy is likely to act as a stateless
proxy for some calls, stateful for others, and as a redirect server
for even others.
Neither stateful nor
stateless proxies need to maintain call state, although they can, but
will need to make sure that they are part of subsequent transactions
via the Record-Route
header.
Proxies must be stateful if
one of the following conditions hold:

uses
TCP,

uses
multicast,

forks.

Why
can a forking SIP proxy not be stateless?A forking SIP proxy cannot
be stateless because it needs to perform a filtering operation,
returning (in general) one response out of the many it receives. For
example, a forking proxy with three branches, that receives a
200-class, 400-class, and 500-class response on each branch
respectively, should return only the 200-class response upstream. If
the proxy were stateless, it would end up returning all three of the
responses upstream (since it won't remember that it had received
prior responses when it gets another one). The result of this is (1)
response implosion at the client, and (2) inconsistent responses at
the client. (In this example, depending on the order the responses
would be received, the client would think that the call failed, just
to get a success indication some time later.) Thus, a forking proxy
must be stateful.
Also note that a proxy that
uses TCP must be stateful as well, whether it forks or not. This has
to do with reliability issues.
Why do you want state in a
proxy? Certain services (like forking) simply require it. A
sequential search proxy requires state; sequential search is the
heart of services like follow-me and personal mobility. It's at the
discretion of the implementor whether to use a stateful or stateless
proxy. You can even be "super stateful", and use the
Record-Route header to allow a proxy to be on the signaling path of
all subsequent exchanges. This allows a stateful proxy to maintain
call state in addition to transaction state.
How
does a caller find the remote SIP client of the callee?The process is similar to
the delivery of email: The caller uses the SIP host name to look up
the destination host, first trying a NAPTR/SRV record and then
"regular" DNS, just like an email client (MTA) looks up the
MX record. (NAPTR/SRV records are generalized MX records applicable
to any network service, including, but not limited to, SIP and RTSP.)
For example, when contacting bell@cs.columbia.edu the client finds a
NAPTR/SRV record pointing to erlang.cs.columbia.edu as the SIP server
for the domain cs.columbia.edu. As for email, a single domain name
can resolve to multiple servers, allowing load sharing and
redundancy. (NAPTR assists in selecting the (server
that supports the)
desire transport, e.g. SIP over TCP)
The server located in this
manner can then proxy or forward the call to another server.How
does SIP get through a firewall or NAT?There are several possible
approaches to SIP-capable firewalls. One of the difficulties is that,
unlike for, say, HTTP, connections are originated both by hosts
inside and outside the firewall. A likely arrangement is that a SIP
proxy sits "on" the firewall and relays SIP requests
between the Internet and the intranet. This proxy would also open up
the necessary ports in the firewall to let audio and video flow
through, for example using Socks
V5. (Such server would normally be referred to as ALG (App. Layer
Gateway))
As an alternative, if a
firewall or NAT allows outgoing TCP connections, the inside client
can open up a TCP connection to an outside proxy. All outgoing and
incoming calls would then be handled by that TCP connection. (The
client would still have to use SOCKS or similar mechanism to convince
the firewall to let RTP packets through.)
As of 2006 the key
solutions for NAT/firewall traversal are: SBC (Session Border
Controller), ALG and using the STUN protocol (RFC 3489).How
does SIP do "call progress tones" or "ring back"?The
SIP server being called, such as an Internet telephony gateway, can
return any number of provisional status messages that indicate call
progress. Typically, this is just 100 (Trying) followed by 180
(Ringing), but a server could produce elaborate feedback such as

100 Message received

100 Looking up number

100 Found number, looking up carrier according
to profile

100 Finding cheapest carrier which doesn't do
animal testing

100 Found carrier "AT&T"

100 Dialing number

180 Ringing

182 Queued, 3 people in front of you

182
Queued, 2 people in front of you

The
language of the status message should be determined based on the
Accept-Language
request header in the call.

A
183 (Session Progress) status response will appear in RFC2543bis. It
can be used for both progress tones as well as error messages.

One would use the 183 only
if you:

Are
able to determine that the audio being generated is something
other than ringing (e.g. "comfort tone" or "pay
tone" as defined in E.18x), or

Are
unable to definitively determine that alerting is occuring. This
really should only happen with older CAS protocols. ISUP and ISDN
have sufficient information to determine what is happening on the
far end.

One can also use 183 if the
gateway is able to determine that an error has occured, but that
there is a tone or announcement accompanying it (e.g., an ACM with a
cause code present). In that case, the gateway can send a 183 to set
up the media for the announcement (ideally with the announcement text
as the text string), wait for a timer (on the order of 30 seconds),
and then send an appropriate SIP error message.
However, this should only
be done if the caller is likely a human being, as sending 183 would
otherwise only delay failure handling.Does
SIP do keep-alive?Originally it didn't, but
now it does. See Session
Timers (RFC 4028). (Thank you Vagelis Kalligeris for the
typo correction!)Why
does SIP not have a Content-Transfer-Encoding header?The
Content-Transfer-Encoding
header was primarily meant to allow message bodies to be transformed
into formats that could be transferred on channels that were not 8
bit clean. HTTP, which makes use of many of the MIME headers, is 8
bit clean, and thus did not need Content-Transfer-Encoding.
SIP followed suit, and so does not use it either. Content-Encoding
is used for things like compression, which is different. (J.
Rosenberg)
See also RFC 2616
(HTTP/1.1), Section 19.4.5.I
want SIP to be more compact. What can I do? First, one should realize
that in general, SIP exchanges are only going to be a tiny fraction
of the overall session bandwidth. A typical SIP call setup takes less
than 1000 bytes, or the equivalent of one second of highly compressed
(G.729) audio. Some additional space savings can be realized by using
short headers. (IMS makes things a bit more complicated though due to
its many extensions)
In general, more
substantive savings are possible by using either Rohc/Signaling
Compression (SigComp RFC 3320/3321/3486 etc) or IP payload
compression (RFC
2393) or link-layer compression, e.g., at the PPP layer. For the
example above, the total size is reduced to about 520 bytes with gzip
compression.
What
are the different addresses in SIP?SIP INVITE requests involve
three addresses:

The
host address where the request came from. Responses are sent back to
the same host address, regardless of what the From
header indicates. Note that different requests for the same call can
come from different hosts.

The
From
address contains the logical source of the request. It remains
unmodified as a SIP request traverses proxies, for example. The From
address may not be the same as the host address that generated the
SIP request, although that's the typical case.

The session
description (e.g., SDP) contains one or more addresses where the
caller expects media data (audio, video) to be sent. For some
services, this address may not be the same as the From
address.

How
do I put call on hold?There are several
"traditional" ways to do that, e.g. zeroing the IP address
or port number in the media descriptor of the stream to be placed on
hold. However the most correct and up-to-date way is to set media
attribute parameter to 'inactive or sendonly', i.e. "a=inactive"
or "a=sendonly".In
what practical scenarios Call-Info header is(/can be) used?The Call-Info header field is included in a request by a UAC or
proxy to provide a URI with information relating to the session
setup. It may be presentin an INVITE, OPTIONS or REGISTER request. The header field
parameter purpose indicates the purpose of the URI and may have the
valuesicon, info, card, or other IANA registered tokens. An example
follows:Call-Info:
<http://www.code.com/my_picture.jpg>;purpose=icon.
(Karimulla Sayed)

---
Relationship To Other Protocols---

Does
SIP do conference control?SIP leaves conference
control, such as the election of a chair or floor control, to other
protocols. SIP can be used for non-conferencing applications and
floor control may be used outside the scope of SIP-initiated calls,
so it seemed best to separate the functionality. However, SDP may be
used to indicate which media are subject to floor control and what
tools and protocols are to be used. This is work in progress mainly
in the IETF
and OMA
standardization bodies.What
is the relationship between MGCP/Megaco/H.GCP and SIP?The details of combining
the two in a system are still being fleshed out. MGCP is a device
control protocol,
where a slave (gateway (MG)) is controlled by a master (media gateway
controller (MGC), call agent). SIP may be used between
controllers, in a peer-to-peer relationship. Note that to the SIP
side, the MGC looks like a node with a large number of connections,
but otherwise the same as a "native" SIP device. Similarly,
the MG is completely unaware that the call between MGCs is
established via SIP. Only the MGC needs to understand both protocols.What
is SIP+ and how does it relate to SIP?SIP+ was a proposal by
Level3 on how to extend SIP to interconnect two MGCs. This
functionality is now being provided by various orthogonal SIP
extensions, including the carriage of multipart MIME types, the INFO
method and others. These are being documented in a BCP draft. The
name SIP+ is obsolete and should not be used to avoid confusion.How
does SIP compare to H.323?The H.323 protocol came on
the scene in the mid-'90s as a transmission and session setup
protocol for videoconferencing over ISDN networks. It comes out of
the International Telecommunication Union (ITU), a 54-year-old
standards body for technologies and protocols for the international
phone network. H.323 is not a single protocol in one vertical
integrated stack, but it is a suite of protocols that cover codecs,
call control, conferencing, and many other functions. The
advantage to this approach is that by strictly controlling so many
aspects of the implementation it is easier to ensure that H.323 based
systems function well together. On the down side, H.323 has
become heavy and cumbersome. Flexibility is sacrificed as one is tied
to a single family of technologies. For a field as young and fast
changing as IP telephony, where many problems and solutions are still
under debate, flexibility is an important aspect. SIP is part of
this flexible approach, as it uses a wide variety of protocols, each
addressing a different aspect of the problem space. The advantage is
the ability to choose from among many competing technologies and move
to newer and better ones as they emerge. This has always been the
philosophy behind SIP and this is the approach of the IETF to IP
telephony in general. (Taken from SIP Illustrated)
Can
SIP be used for Internet telephony gateways (ITGs)?Yes, in two ways. First, it
can indicate to the Internet-based caller that the callee is
reachable via an ITG, via the Contact
header. Secondly, two ITGs connecting parties on the PSTN can signal
new calls to each other, with the destination phone number contained
in the request URL.Can
H.323 and SIP be used together?

Yes.
SIP can locate the called party and determine its capabilities,
including H.323. H.323 is then used to connect the two parties.

Unfortunately,
there is currently no specification on translating between the two.
Conversion is made more difficult by the multiple versions of H.323
(v1, v2, v3). However, there are several gateway products in the
market place that allows SIP and H.323 terminals to call each other.

How
do I interconnect Q.931 (ISDN signaling) and SIP?A gateway that initiates an
ISDN call based on a SIP call or vice versa is reasonably
straightforward.How
do I interconnect ISUP (SS7 signaling) and SIP?Similar to the above. SIP-T
and SIGTRAN provide standardization in this area.What
is sip-cgi and how does it relate to CPL?Both are viewed as
different approaches for creating VoIP services. Both are written
offline, and both are executed when messages arrive in order to
execute features.

CPL
is an XML-based language, while sip-cgi is a mechanism for invoking
scripts or programs written in any language. sip-cgi is very similar
to web cgi scripts.

In
its current version, CPL is only invoked when INVITE
requests and responses arrive, while sip-cgi can intercept any
request.

sip-cgi is designed to be
used by SIP, while CPL can probably be used by a number of signaling
protocols such as Q.931 or H.323.
CPL and sip-cgi differ in
their applicability. CPL is designed for end user service creation.
It is intentionally limited in capabilities and is not a general
purpose programming language. Its execution on a server is generally
very fast. CGI is more powerful - you can do nearly anything. It is
programming language independent. It incurs a process-spawning
overhead, so its less efficient than CPL. (CPL is usually executed in
the same process as the server). As a service provider, I would not
want to execute CGI scripts sent to me by end users. However, I would
prefer to use CGI to develop my own services.
Note that CGI may be used
as the execution environment for a CPL script. (Jonathan Rosenberg)
Is
there a SIP interoperability certification? How can I test
interoperability with others?Check out the SIPit
events (IOT) and the SIP Forum
(certification).

---
SIP Implementation/tools---

Is
there any free testing tool, which can build SIP messages and upon
reception can respond with
specific predefined response?SIPp (this is not a
typo...) (http://sipp.sourceforge.net)
is a fantastic tool for accomplishing what I think you're after.
[Rhys Ulerich]Is
there any tool that generates SIP log (call trace)?Yes. check out Call
Analyzers from: Ethereal (www.ethereal.com),
Empirix (www.empirix.com),
QuadTex (www.quadtexsys.com).Are
there any tools that would allow generation of graphical
SIPcallflows?You might want to look at
SIP Scenario: http://www.iptel.org/~sipsc/
It does a few things that the
Ethereal analyser doesn't, but takes a little more effort to
configure (Michael Procter). Also Ethereal does this itself after the
10.2 version.

Should
a terminal, which is intended to transmit calls to the PSTN, support
TRIP (Telephony Routing Over IP) or is it only the problem

of
the gateway?

TRIP is not needed in end
user phones or PC clients. It is used between servers facing each
other in a peering relationship between serviceproviders. Usage
scenarios for TRIP are described fully in:
http://www.ietf.org/rfc/rfc2871.txt

A
client or PC phone which wishes to make a call to the PSTN can do one
of several things. Starting with the most commonly implemented
one:

1. If the phone is in domain foo.com, it constructs a SIP
URL of the form sip:<dialed-number>@foo.com, puts that in the
request URI, and sends the request. The server for its domain figures
out what to do, using things like ENUM, TRIP, or statically
configured routing tables.

2. The phone inserts a tel URL into
the request URI, of the form tel:<dialed-number>, and sends it
to its proxy. From there, things proceed as above in step 1.

3.
The phone uses ENUM itself, and possibly gets back a SIP URL for that
number, which it can use directly. If the ENUM query fails to yield a
SIP URL (which will be a frequent occurence), proceed to step 1 or
2.

SIP
servers are plain hosts on the Internet or the intranet. They do not
do IP routing. they only forward SIP messages just like email agents
do with email messages (SMTP). IP routers are NOT SIP aware. Normally
they do not look at IP packets beyond the IP header bits, thus they
have no idea whether the payload is SIP, HTTP, SMTP, DNS, Telnet, FTP
or something else.

1.2Any
relation between SIP URL and IP address?

Not
really. SIP URL is an application layer Identifier, similar to an
email or web address. It is associated with a person not a computer.
IP address is associated with a computer (see the IP Basics section
above). Hence a computer may host multiple SIP URLs (even at the same
time). In addition, the same SIP URL might be hosted by different
computers (even) at the same time). The association between SIP URL
and IP address (of a SIP phone) is done at the SIP Registrar by a
process known as SIP Registration.

1.3Can
SIP work with IPV6?

Yes,
as long as the device that routes the SIP messages support IPV6.

1.4How
does SIP differ from Mobile IP (MIP)?

SIP
phone needs to know the IP address of the next SIP hop in order to be
able to forward/send it a SIP message. However, it doesn't know
and/or doesn't care whether the next hop stays all the time at the
same place or whether it moves, as long as the IP packet, which carry
the SIP message can reach it. should the next hop move (and thus
possibly change its point of attachment to the Internet) MIP can take
care of the physical delivery of the IP packets destined to it.

1.5If
a SIP UAS is unreachable, will the UAC get a SIP error code or an
ICMP error?

It
is a bit like mixing apples and vegetables... For instance, a device
might be IP/ICMP reachable, and even SIP reachable, and yet the SIP
URL might be wrong or not handled by the destination SIP device, and
thus a SIP "404 Not Found" might be returned. In a
different situation the SIP URL might be valid, but the target host
has crashed and thus the router at the destination network may return
ICMP error code 1 (Host Unreachable). Needless to say, in a situation
like that there is no target SIP application alive that can send any
SIP error back...

1.6Can SIP messages get
fragmented by IP nodes?

In
theory yes. However the SIP standard tries to prevent this situation
by recommending the use of congestion controlled transport protocol,
(such as TCP) in case a request is within 200 bytes of the path MTU
or larger than 1300 bytes (and the path MTU is unknown). The
motivation for preventing fragmentation of SIP messages is having
practical issues with some of the real time IP stacks.

1.7Is
it a must for SIP to work with IP?

In
theory no, but practically that's always the case.

1.8What are codecs? What's
the relation between them and SIP?

Codecs
are hardware/software means that are used to encode analog
audio/video signals in binary digital format. Codecs are mainly
different from each other by the sampling rate (~bandwidth) and
number of bits they use to encode the signal samples. In VoIP they
are normally used as the payload of RTP, e.g. G711/RTP, H261/RTP etc.
SIP does not use codecs, but as part of in the call setup SIP end
points indicate (via SDP/SIP) what codecs they will use in the
conversation phase (RTP).

1.9Do 3GPP/3GPP2 use SIP?

Yes
they do. 3GPP adopted SIP in 2001. Your humble slaves were involved
in the discussions that preceded that critical decision (i.e.
preferring it on H323). 3GPP came up with the IMS (IP Multimedia
subsystem), which is their way to implement VoIP services over GPRS
and UMTS cellular networks. Defacto IMS can support any access
network technology including Wi-Fi, CDMA and others. 3GPP2 (CDMA 3rd
generation) are in a catch up mode. They are quickly adopting the
3GPP IMS design. There are some nuances between the 3GPP IMS and the
3GPP2 IMS, but these are not major. The 3GPP2 folks call their IMS -
MMD (Multimedia Domain) or All IP core.

1.10What
is PTT? What is PoC? How are these related to SIP?

PTT
stands for Push To Talk. This is the telephony technology which
simulates walkie talkie type of communication. It has become very
popular in the wireless arena. Typically when people hear this term
they say "Oh, the Nextel phones...". PoC stands for PTT
over Cellular. The OMA standard organization defines how PoC should
work. They base their work on SIP (and RTP/RTCP).

1.11How
do you do billing for SIP? PTT? PoC? IMS?

Diameter
(IETF RFC 3588) seems to be the protocol of choice for doing billing
(charging). It was adopted by 3GPP. Most likely the closely related
standard organizations will follow suit.

1.12How
do you do lawful intercept for those...?

Standard
takes care of this too. The main idea is to intercept and report to
the authorities both events and data, and do so in a common way for
all VoIP related technologies/systems.

1.1What’s the difference
between GPRS and UMTS?

This
is quite confusing for many people. According the 3GPP standard (TS
23.060) GPRS defines the packet data services provided by a common
core network to two main types of access networks - GSM based
and WCDMA based (UMTS).

1.2What’s
the relation between GPRS and IP?

GPRS
uses IP based signaling/control protocols between its components.
Beyond that it transparently carries IP packets between the mobiles
and the Internet. This is done by method known as encapsulation and
tunneling.

1.3Can you do
voice calls with GPRS?

GPRS
provides an IP data pipe. Therefore by definition you can do anything
on top of it including voice. QoS is a major issue though for voice
over GPRS, and IMS (IP Multimedia Subsystem) tries to resolve it.

1.4What is the
relation between GPRS and SIP?

SIP
rides transparently over GPRS just like any other IP based protocol.
IMS and QoS muddy this picture a bit. You can read all about it in 3G
IMS Illustrated.

1.5What is the
relation between UMTS and SIP?

Same
as GPRS.

1.6What is the
relation between CDMA (1X) and SIP?

Very
similar to GPRS/UMTS and SIP. the designers of CDMA 1X (3GPP2) has
adopted the 3G way (IMS) for doing VoIP/multimedia.

1.7Does SIP care
at all about the access network that uses it?

No,
apart from QoS impact, which may dictate what codecs will get used
and what quality you may expects from a multimedia session.

1.8Can SIP run on
top of 802.11?

Sure.
In SIP's eyes 802.11 is just another type of access network, which
can carry it.