<?xml version="1.0" encoding="utf-8"?>
<!-- generator="FeedCreator 1.7.2-ppt DokuWiki" -->
<?xml-stylesheet href="http://wiki.voip.co.uk/lib/exe/css.php?s=feed" type="text/css"?>
<rss version="2.0">
    <channel>
        <title>wiki.VoIP.co.uk sip</title>
        <description></description>
        <link>http://wiki.voip.co.uk/</link>
        <lastBuildDate>Sun, 14 Mar 2010 15:37:20 +0000</lastBuildDate>
        <generator>FeedCreator 1.7.2-ppt DokuWiki</generator>
        <image>
            <url>http://wiki.voip.co.uk/lib/images/favicon.ico</url>
            <title>wiki.VoIP.co.uk</title>
            <link>http://wiki.voip.co.uk/</link>
        </image>
        <item>
            <title>sip:case</title>
            <link>http://wiki.voip.co.uk/sip/case</link>
            <description>Element      Case Sensitive?  Via branch   insensitive (token)  Call-ID      sensitive - Byte for byte compare  SIP-Version  insensitive - must send uppercase though  Header field names  insensitive 

From RFC 3261, sect 7.3.1:

When comparing header fields, field names are always case-insensitive.  Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive.  Tokens are always case-insensitive.  Unless specifie…</description>
        <category>sip</category>
            <pubDate>Thu, 05 Feb 2009 16:34:19 +0000</pubDate>
        </item>
        <item>
            <title>sip:digest</title>
            <link>http://wiki.voip.co.uk/sip/digest</link>
            <description>Calculating a digest response header for MD5 without qop is simply a matter of concatenating the HA1, nonce, and HA2:

response = MD5(HA1, nonce, HA2)

A1 is calculated as

HA1 = MD5(username &quot;:&quot; realm &quot;:&quot; password)

A2 is:

HA2 = MD5(method &quot;:&quot; uri)

Note that this means you can store just the HA1, you don't need to keep the plaintext password in order to be able to authenticate users.  Of course, the HA1 can still be used for authenticating against that realm and user, but it doesn't reveal th…</description>
        <category>sip</category>
            <pubDate>Sun, 28 Oct 2007 18:48:10 +0000</pubDate>
        </item>
        <item>
            <title>sip:faq</title>
            <link>http://wiki.voip.co.uk/sip/faq</link>
            <description>What is the &quot;R-URI&quot;


The Request-URI.  This is the URI contained in the very top line of any request.  In this example, the R-URI value is sip:+441869118000@biloxi.com;user=phone:

INVITE sip:+441869118000@biloxi.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 1.2.3.4:5060;branch=xxxxx
From: Bob &lt;sip:bob@biloxi.com&gt;
To: Alice &lt;sip:alice@atlanta.com&gt;;tag=xxx
CSeq: 1 INVITE
Call-ID: 32f3-fk35-fkl45-fk45fg45

Note that the To header URI may be totally different from the R-URI in a random SIP message in a …</description>
        <category>sip</category>
            <pubDate>Fri, 01 Aug 2008 21:19:26 +0000</pubDate>
        </item>
        <item>
            <title>sip:gruu</title>
            <link>http://wiki.voip.co.uk/sip/gruu</link>
            <description>When implementing with sip-outbound and a UA has multiple outbound flows for redundancy, the UA must use the same Call-ID otherwise each register will invalidate the temp-gruu assigned by the other.  this implies that the CSeq should also be shared among the registrations.</description>
        <category>sip</category>
            <pubDate>Sun, 11 Nov 2007 02:51:23 +0000</pubDate>
        </item>
        <item>
            <title>sip:matching_using_to_header</title>
            <link>http://wiki.voip.co.uk/sip/matching_using_to_header</link>
            <description>RFC 3261 defines the To header field to contain the logical recipient of a request, which of course does not have any 
representation to that of the target of a given branch.

To make this more clear, the To and From header fields are end to end header fields populated by the originating UA, and not modified by the network.  A UA is free to place whatever it likes in this field, as it is not used in any routing or targeting decisions.</description>
        <category>sip</category>
            <pubDate>Fri, 18 Jan 2008 00:12:03 +0000</pubDate>
        </item>
        <item>
            <title>sip:start</title>
            <link>http://wiki.voip.co.uk/sip/start</link>
            <description>*  SIP Protocol Frequently Asked Questions
	*  Some comments on digest authentication.
	*  Underspecified situations in the protocol
	*  GRUU notes
	*  Status Codes we send back to SIP UAs
	*  Role of the To header in SIP requests.
	*  Some SIP protocol and stack tests
	*  T.38 examples</description>
        <category>sip</category>
            <pubDate>Fri, 19 Dec 2008 07:59:32 +0000</pubDate>
        </item>
        <item>
            <title>sip:status.codes</title>
            <link>http://wiki.voip.co.uk/sip/status.codes</link>
            <description>This page is designed for information working with SIP at a packet level.  It is expected the reader has complete knowledge of RFC 3261.

A number of status codes are sent back from our platform that can do with having a little more description attached to them to aid debugging.</description>
        <category>sip</category>
            <pubDate>Fri, 23 Nov 2007 13:08:19 +0000</pubDate>
        </item>
        <item>
            <title>sip:t.38</title>
            <link>http://wiki.voip.co.uk/sip/t.38</link>
            <description>Example T.38 offer sent by a Cisco AS5350XM on detecting FAX:


v=0
o=CiscoSystemsSIP-GW-UserAgent 1107 1281 IN IP4 192.168.0.1
s=SIP Call
c=IN IP4 192.168.0.1
t=0 0
m=image 33884 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy</description>
        <category>sip</category>
            <pubDate>Fri, 19 Dec 2008 08:00:25 +0000</pubDate>
        </item>
        <item>
            <title>sip:tests</title>
            <link>http://wiki.voip.co.uk/sip/tests</link>
            <description>I do a fair bit of SIP interoperability testing and testing other UA devices for compliance before offering them to customers.

As such, i'm slowly building up a list of edge cases that are often overlooked when developers write SIP stacks and TU's.</description>
        <category>sip</category>
            <pubDate>Sun, 07 Jun 2009 04:48:14 +0000</pubDate>
        </item>
        <item>
            <title>sip:underspecified</title>
            <link>http://wiki.voip.co.uk/sip/underspecified</link>
            <description>There are a number of situations in the SIP protocol (RFC 3261 &amp; extensions) where behaviour is allowed, but underspecified.  While some of these are edge cases, others are just due to just not having any defined behaviour or not defined well enough.</description>
        <category>sip</category>
            <pubDate>Sun, 28 Oct 2007 23:33:50 +0000</pubDate>
        </item>
    </channel>
</rss>
