{"id":1135,"date":"2019-09-07T15:10:03","date_gmt":"2019-09-07T05:10:03","guid":{"rendered":"https:\/\/nickvsnetworking.com\/?p=1135"},"modified":"2019-08-30T16:01:09","modified_gmt":"2019-08-30T06:01:09","slug":"sip-extensions-path","status":"publish","type":"post","link":"https:\/\/nickvsnetworking.com\/sip-extensions-path\/","title":{"rendered":"SIP Extensions &#8211; Path"},"content":{"rendered":"\n<p>In vanilla RFC3261 SIP, a UA can only <a href=\"https:\/\/nickvsnetworking.com\/what-is-a-sip-registrar\/\">send a REGISTER request to a SIP Registrar.<\/a><\/p>\n\n\n\n<p>It can&#8217;t go via any intermediary proxies.<\/p>\n\n\n\n<p>That&#8217;s obviously a bit of a problem, as we build out our network we might have a series of load balancers that send traffic to a pool of Registrars, but according to RFC3261 this can&#8217;t be done, the SIP REGISTER request would need to go direct to one of these Registrars.<\/p>\n\n\n\n<p>To get around this the SIP Path extensions, officially called &#8220;Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts&#8221; (catchy title) was defined under <a href=\"https:\/\/tools.ietf.org\/html\/rfc3327\">RFC 3327.<\/a><\/p>\n\n\n\n<p>An additional header is introduced called &#8220;Path:&#8221; for each proxy between the UA and the Registrar,<\/p>\n\n\n\n<p>As the SIP REGISTER request passes through each proxy, each proxy appends the Path header with the value of it&#8217;s own SIP URI.<\/p>\n\n\n\n<p>Let&#8217;s take a look at an example call flow from bob@biloxi.com who sends his REGISTER to atlanta.com, which is proxied by atlanta.com to registrar1.atlanta.com:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Bob to atlanta.com:<\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>bob@biloxi.com > atlanta.com\n      REGISTER sip:atlanta.com SIP\/2.0\n      Via: SIP\/2.0\/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7\n      To: Bob &lt;sip:bob@biloxi.com>\n      From: Bob &lt;sip:bob@biloxi.com>;tag=456248\n      Call-ID: 843817637684230@998sdasdh09\n      CSeq: 1826 REGISTER\n      Contact: &lt;Bob &lt;sip:bob@biloxi.com>>\n      Supported: path<\/code><\/pre>\n\n\n\n<p>The REGISTER request is received by atlanta.com, which forwards it to registrar1.atlanta.com after adding it&#8217;s own URI as a Path header.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>atlanta.com > registrar1.atlanta.com\n      REGISTER sip:atlanta.com SIP\/2.0\n      Via: SIP\/2.0\/UDP atlanta.com;branch=z9hG4bK34ghi7ab04\n      Via: SIP\/2.0\/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7\n      To: Bob &lt;sip:bob@biloxi.com>\n      From: Bob &lt;sip:bob@biloxi.com>;tag=456248\n      Call-ID: 843817637684230@998sdasdh09\n      CSeq: 1826 REGISTER\n      Contact: &lt;Bob &lt;sip:bob@biloxi.com>>\n      Supported: path\n      Path: &lt;sip:atlanta.com;lr><\/code><\/pre>\n\n\n\n<p>The response is sent back in the same way, relying on the via headers and Path headers.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>In vanilla RFC3261 SIP, a UA can only send a REGISTER request to a SIP Registrar. It can&#8217;t go via any intermediary proxies. That&#8217;s obviously a bit of a problem, as we build out our network we might have a series of load balancers that send traffic to a pool of Registrars, but according to &hellip; <a href=\"https:\/\/nickvsnetworking.com\/sip-extensions-path\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">SIP Extensions &#8211; Path<\/span> <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,2],"tags":[70,236,8,237],"class_list":["post-1135","post","type-post","status-publish","format-standard","hentry","category-standards","category-voip","tag-rfc-3261","tag-rfc3327","tag-sip","tag-sip-path"],"_links":{"self":[{"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/posts\/1135","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/comments?post=1135"}],"version-history":[{"count":4,"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/posts\/1135\/revisions"}],"predecessor-version":[{"id":1142,"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/posts\/1135\/revisions\/1142"}],"wp:attachment":[{"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/media?parent=1135"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/categories?post=1135"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nickvsnetworking.com\/wp-json\/wp\/v2\/tags?post=1135"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}