Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Aboutsip - SIP Routing

8,248 views

Published on

To fully appreciate SIP you need to understand its routing capabilities and how they enable SIP to traverse a network. These capabilities also help SIP deal with common network issues such as NAT and firewalls. SIP's flexible routing also enables features like application composition, a very valuable asset when designing, implementing, and building a loosely coupled system.

This presentation is for those that are looking to get a deeper understanding of SIP. Perhaps you have been tasked to spin up a completely new SIP infrastructure at work? Then you really need to understand how SIP finds its way through a network. By understanding the routing decisions SIP makes, you will be successful in your next SIP endeavor.

Questions that will be answered:

- How does a SIP request traverse the network?
- How do we know which transport to use?
- How do responses find their way back?
- Any difference for in-dialog requests?

Published in: Technology
  • Be the first to comment

Aboutsip - SIP Routing

  1. 1. @borjessonjonas About SIP SIP Routing Jonas Borjesson
  2. 2. @borjessonjonas NOTE ● This presentation has been recorded and can be viewed here: vimeo.com/140267478 ● This version has been adapted to be viewed without transitions. ● Go to aboutsip.com to download the original version. ● Follow @borjessonjonas to receive updates.
  3. 3. @borjessonjonas Routing ● Understanding SIP routing is a must! ● SIP's flexible routing is what makes SIP so great*. ● The routing capabilities of SIP enables: ● Loosely coupled systems ● Ability for a very flexible application composition model ● NAT/FW Traversal ● CONFUSION! *According to myself. Many people may disagree...
  4. 4. @borjessonjonas Questions ● How does a SIP request traverse the network? ● How do we know which transport protocol to use? ● How do the responses find their way back? ● Any difference for in-dialog requests?
  5. 5. @borjessonjonas What do we need? ● In order to send a request we need to know: ● The IP-address of the destination (or the next hop) ● The port to send it to. ● Which transport to use (udp, tcp, tls or sctp?) ● So, how do we do this?
  6. 6. @borjessonjonas Locating SIP Servers ● RFC 3263 has all the answers. ● Makes use of DNS ● NAPTR lookup to find transport ● SRV lookup to find the port ● A-record lookup to find the IP-address
  7. 7. @borjessonjonas Find the transport ● If transport is specified, use it sip:alice@aboutsip.com;transport=udp ● If target is numeric IP, use UDP sip:alice@192.168.0.100 ● If no transport and target is not numeric but port is specified, use UDP* sip:alice@aboutsip.com:5090 ● If none of the above, do a NAPTR lookup on target IN NAPTR 10 10 "S" "SIPS+D2T" "" _sips._tcp.aboutsip.com IN NAPTR 20 10 "S" "SIP+D2T" "" _sip._tcp.aboutsip.com IN NAPTR 30 10 "S" "SIP+D2U" "" _sip._udp.aboutsip.com Locating SIP Servers * but you may use another transport if necessary (e.g. msg > MTU)
  8. 8. @borjessonjonas Find the port ● If port specified, use it. sip:alice@aboutsip.com:5070 ● If target is a numeric IP address and no port specified, use default for the selected transport. sip:alice@192.168.0.100;transport=udp => 5060 sip:alice@192.168.0.100;transport=tcp => 5060 sip:alice@192.168.0.100;transport=tls => 5061 ● Otherwise, perform a SRV query Locating SIP Servers _sip._udp.aboutsip.com 1800 IN SRV 10 10 5060 lb1.aboutsip.com _sip._udp.aboutsip.com 1800 IN SRV 10 10 5060 lb2.aboutsip.com
  9. 9. @borjessonjonas Find the IP Address ● If numeric IP address, use it. sip:alice@192.168.0.100 ● If SRV record lookup was performed, perform A record lookup based on that result. lb1.aboutsip.com ● Otherwise, do a A record lookup based on the domain in the SIP URI. sip:alice@aboutsip.com ● If many IP's are returned, try them top down. Locating SIP Servers lb1.aboutsip.com. 1800 IN A 10.36.10.10 lb1.aboutsip.com. 1800 IN A 10.36.10.11
  10. 10. @borjessonjonas Which URI? INVITE sip:alice@aboutsip.com SIP/2.0 To: “Alice” <sip:alice@aboutsip.com> From: “Bob” <sip:bob@aboutsip.com>;tag=oiu3rlkj ... Contact: <192.168.0.100;transport=tcp> INVITE sip:alice@aboutsip.com SIP/2.0 To: “Alice” <sip:alice@aboutsip.com> From: “Bob” <sip:bob@aboutsip.com>;tag=oiu3rlkj ... Contact: <192.168.0.100;transport=tcp> Route: <sip:outbound.aboutsip.com;lr> Route: <sip:something.else.com;lr> INVITE sip:alice@aboutsip.com SIP/2.0 To: “Alice” <sip:alice@aboutsip.com> From: “Bob” <sip:bob@aboutsip.com>;tag=oiu3rlkj ... Contact: <192.168.0.100;transport=udp> Route: <sip:outbound.aboutsip.com> Route: <sip:something.else.com;lr>
  11. 11. @borjessonjonas For Requests ● If no Route-headers: use Request URI ● If Route-headers: use the top most Route-header ● BUT ● Is “lr” parameter present or not? ● Strict routing vs loose routing ● RFC 2543 vs RFC 3261
  12. 12. @borjessonjonas Hello Bob To: <sip:bob@aboutsip.com> From: <sip:alice@sipflow.io>;tag=oiu3rlkj Call­Id: asik3­afj3­knoiu2lkj CSeq: 1 INVITE Max­Forwards: outbound.sipflow.io aboutsip.com Route: <sip:outbound.sipflow.io;lr> 70 Contact: <192.168.0.100;transport=tcp> Via: SIP/2.0/TCP 192.168.0.100;branch=z9hG4bK­kljhasdf Via: SIP/2.0/TCP 62.4.10.10;branch=z9hG4bK­32BDjdfd INVITE sip:bob@aboutsip.com SIP/2.0 sip:bob@10.36.10.11;transport=udp Via: SIP/2.0/UDP 82.67.45.50;branch=z9hG4bK­dk3imiuj3
  13. 13. @borjessonjonas Hello Back SIP/2.0 200 OK To: <sip:bob@aboutsip.com> From: <sip:alice@sipflow.io>;tag=oiu3rlkj Call­Id: asik3­afj3­knoiu2lkj CSeq: 1 INVITE outbound.sipflow.io aboutsip.com Contact: <sip:10.36.10.11;transport=udp> Via: SIP/2.0/TCP 192.168.0.100;branch=z9hG4bK­kljhasdf Via: SIP/2.0/TCP 62.4.10.10;branch=z9hG4bK­32BDjdfd Via: SIP/2.0/UDP 82.67.45.50;branch=z9hG4bK­dk3imiuj3 ;tag=jalskdjfi
  14. 14. @borjessonjonas Via-headers outbound.sipflow.io aboutsip.com Via:   Via: SIP/2.0/TCP 62.4.10.10;rport=87564;received=62.4.10.10 Via: SIP/2.0/UDP 82.67.45.50;rport=5060;received=10.36.10.0.1 A closer look 192.168.0.100;rportSIP/2.0/TCP ;received=192.168.0.100=5099
  15. 15. @borjessonjonas Subsequent Requests ● During the dialog initiation, a route-set is built (may be empty). ● The route-set is part of the dialog-state and must be preserved. ● Future in-dialog requests will follow that established route. ● The actual request itself is no different from a out-of-dialog request. It will follow the route-headers + request-uri... ●
  16. 16. @borjessonjonas Establishing the Route Set INVITE sip:bob@aboutsip.com SIP/2.0 To: <sip:bob@aboutsip.com> From: <sip:alice@sipflow.io>;tag=oiu3rlkj Call­Id: asik3­afj3­knoiu2lkj CSeq: 1 INVITE Max­Forwards: outbound.sipflow.io aboutsip.com Route: <sip:outbound.sipflow.io;lr> Contact: <192.168.0.100;transport=tcp> Record­Route: <sip:62.4.10.10;transport=tcp;lr> Record­Route: <sip:82.67.45.50;transport=tcp;lr> Subsequent Requests
  17. 17. @borjessonjonas Establishing the Route Set SIP/2.0 200 OK To: <sip:bob@aboutsip.com>;tag=klajsdf From: <sip:alice@sipflow.io>;tag=oiu3rlkj Call­Id: asik3­afj3­knoiu2lkj CSeq: 1 INVITE Contact: <sip:10.36.10.11;transport=udp> Via: ... Record­Route: <sip:82.67.45.50;transport=tcp;lr> Record­Route: <sip:62.4.10.10;transport=tcp;lr> outbound.sipflow.io aboutsip.com Subsequent Requests
  18. 18. @borjessonjonas Dialog State Remote Target: sip:10.36.10.11;transport=udp Route Set:     sip:62.4.10.10;transport=tcp;lr                sip:82.67.45.50;transport=tcp;lr Subsequent Requests Remote Target: sip:192.168.0.100;transport=tcp Route Set:     sip:82.67.45.50;transport=tcp;lr                sip:62.4.10.10;transport=tcp;lr Note: There is more information stored in the dialog state. This example only highlights the routing information.
  19. 19. @borjessonjonas Constructing a Subsequent Request ● Remote target → Request URI ● Route set → Route Headers ● Send like any other request Subsequent Requests Remote Target:  Route Set: sip:10.36.10.11;transport=udp sip:62.4.10.10;transport=tcp;lr sip:82.67.45.50;transport=tcp;lr BYE                               SIP/2.0 ... Route: Route: sip:10.36.10.11;transport=udp sip:62.4.10.10;transport=tcp;lr sip:82.67.45.50;transport=tcp;lr
  20. 20. @borjessonjonas Sending outbound.sipflow.io aboutsip.com Subsequent Requests BYE sip:10.36.10.11;transport=udp SIP/2.0 ... Route: <sip:62.4.10.10;transport=tcp;lr> Route: <sip:82.67.45.50;transport=tcp;lr>
  21. 21. @borjessonjonas Check this out INVITE sip:bob@aboutsip.com SIP/2.0 To: <sip:bob@aboutsip.com> From: <sip:alice@sipflow.io>;tag=oiu3rlkj Call­Id: asik3­afj3­knoiu2lkj CSeq: 1 INVITE Max­Forwards: outbound.sipflow.io aboutsip.com Route: <sip:outbound.sipflow.io;lr> Contact: <192.168.0.100;transport=tcp> Record­Route: <sip:62.4.10.10;transport=tcp;lr> Subsequent Requests Not Record-Routing!
  22. 22. @borjessonjonas Dialog State Remote Target: sip:10.36.10.11;transport=udp Route Set:     sip:62.4.10.10;transport=tcp;lr                sip:82.67.45.50;transport=tcp;lr Subsequent Requests Remote Target: sip:192.168.0.100;transport=tcp Route Set:     sip:82.67.45.50;transport=tcp;lr                sip:62.4.10.10;transport=tcp;lr Note: There is more information stored in the dialog state. This example only highlights the routing information.
  23. 23. @borjessonjonas Sending outbound.sipflow.io aboutsip.com Subsequent Requests BYE sip:10.36.10.11;transport=udp SIP/2.0 ... Route: <sip:62.4.10.10;transport=tcp;lr>
  24. 24. @borjessonjonas Summary
  25. 25. @borjessonjonas Summary ● RFC 3263 is important! Read it! ● RFC 3261 explains which the “next uri” is: ● Requests – follows Route-headers plus Request-URI ● Responses – follows Via-headers ● Watch out for the old strict routing. ● Subsequent requests are really no different. ● Make sure you understand remote-target + route set as stored in the Dialog State.
  26. 26. @borjessonjonas More presentations and material at aboutsip.com Thanks!

×