WarmTransfer
sip media · published

SIP call forwarding and routing loops

Verified 2026-09-25 · 49 sources · tier 1–2

RFC 3261 requires a SIP user agent client (UAC) to insert a Max-Forwards header field with an initial value that should be 70 into each originated request 46. When routing loops or call-forwarding cascades occur, proxy servers, back-to-back user agents (B2BUAs), and specific call control engines rely on hop-count decrements and loop-detection headers to terminate repeating transactions 34​2​4.

How it works

The SIP Max-Forwards header field limits the number of hops a request can make toward its destination and holds an integer decremented by 1 at each hop 34. When forwarding a request, a SIP proxy decrements Max-Forwards by 1, and if the request carries no Max-Forwards header field, the proxy adds one with the value 70 36. A SIP proxy that receives a request whose Max-Forwards value is 0 must not forward it and returns 483 Too Many Hops, although it may answer an OPTIONS request addressed to itself 35. The response code 483 Too Many Hops indicates that the server received a request whose Max-Forwards value was 0, whereas 482 Loop Detected indicates that the server detected a loop 2.

RFC 3261 gives proxies an optional loop-detection check that inspects Via header values (sent-by plus branch parameter) and responds with 482 Loop Detected upon finding a loop 1. RFC 3261 distinguishes a spiral from a loop: a request returning to the same proxy with a different Request-URI (such as following call forwarding) is a spiral and represents legitimate signaling rather than a loop 39.

RFC 5393 (December 2008, Standards Track) normatively updates RFC 3261 to fix an amplification vulnerability in which forking proxies without loop detection turn a few requests into very large amounts of proxy-to-proxy traffic 38. Under RFC 5393, any proxy forking a request to more than 1 destination must ensure the request is not looping through it; Via-based detection is recommended, but other mechanisms are permitted 23. RFC 5393 also defines the Max-Breadth header field to limit concurrent forked branches for a request, recommending an initial value of 60 33.

For B2BUA deployments, RFC 7332 mandates that every type of SIP B2BUA copy the Max-Forwards value received on its UAS side into requests generated on its UAC side and decrement that value 4. If the incoming request lacks a Max-Forwards field, the B2BUA must create one on its UAC side, with a recommended value of 70 5. RFC 7332 requires B2BUAs to check the received Max-Forwards value and reject or respond to the request rather than pass it on if the value is 0 3. RFC 7332 further recommends that B2BUAs implement the Via-based loop detection defined in RFC 5393 and requires copying any received Max-Breadth header field into outgoing requests 7. WarmTransfer's reading of the sources is that an SBC or PBX acting as a B2BUA that resets each outgoing leg to a fresh Max-Forwards value prevents the count from ever hitting 0 during a carrier loop, preventing termination via 483 6.

Retargeting and call history headers

RFC 7044 (February 2014) defines the SIP History-Info header to record how and why a request reached its target through retargeting such as forwarding, obsoleting RFC 4244 25. Each History-Info entry includes a mandatory index parameter formatted as dot-separated integers (such as 1.1.2) that preserves the chronological order and branching structure of retargeting hops 24. History-Info entries can also include a Reason header containing the SIP response code triggering the retargeting, such as 302 for unconditional forwarding, 486 for busy, 408 for timeout, or 480 for temporarily unavailable 26.

The SIP Diversion header is documented in RFC 5806 (March 2010) with Historic status; an IESG note therein points to History-Info (RFC 4244) as the standard mechanism selected instead 19. The Diversion header specifies a counter parameter, and RFC 5806 indicates that the ISUP Redirection Counter should match the sum of all counter parameters across Diversion headers in the SIP message 18.

Platform differences

Cisco Unified Communications Manager (CUCM)

In Unified CM 15, the Forward Maximum Hop Count service parameter (under System > Service Parameters) defines how many times a single call may be forwarded or diverted 14. Incoming QSIG calls cap diversions at 15 regardless of whether Forward Maximum Hop Count is set higher, and Cisco recommends configuring the parameter to 15 when using QSIG trunks 16.

Unified CM enforces Call Forward All (CFA) loop prevention when activated from a phone, blocking changes if the destination creates a loop (such as extension 1000 forwarding to 1001 when 1001, 1002, and 1003 already forward back to 1000) 12. However, Unified CM does not prevent a CFA loop if Call Forward All is configured through Unified CM Administration or the Self Care Portal 9. The phone-based activation block requires that every node in the chain use CFA (rather than CFB or CFNA) and that the chain exceed Forward Maximum Hop Count 13. Unified CM also provides CFA loop breakout to preserve call processing if a loop already exists, allowing the call to traverse the chain and break out 10. The Max Forward UnRegistered Hops to DN service parameter separately sets the number of concurrent forward-unregistered hops permitted for a directory number 17. When CFA Destination Override is enabled, Unified CM overrides forwarding if the CFA destination matches the calling party number, ringing the initiator directly instead of returning through the loop 11.

Cisco IOS, IOS XE, and CUBE

On Cisco IOS and IOS XE gateways and CUBE, the max-forwards command under sip-ua configuration mode defines the SIP maximum hop count from 1 to 70 (default 70) 29. This command was introduced in 12.1(3)T, and its range and default were expanded in 12.3(8)T to comply with RFC 3261 28. In IOS 15.6(2)T and IOS XE Denali 16.3.1, max-forwards was added to voice class tenant mode, where the system keyword reverts tenant behavior to the global configuration 30. Cisco IOS also provides the max-redirects command to control the maximum number of redirects allowed 31.

Dial-peer groups in Cisco IOS and IOS XE can bind outbound dial-peers directly to matching inbound dial-peers, restricting exit paths for inbound trunk calls 27. WarmTransfer's reading of the sources is that configuring an inbound dial-peer on CUBE with a dial-peer group that excludes the originating carrier trunk stops the SBC from hairpinning carrier traffic back out to the same provider 8. Dial-peer selection and SIP messages can be verified using debug voip ccapi inout and debug ccsip messages 32.

Cisco Expressway and VCS

On Cisco VCS, a request forwarded through a zone uses the lower of its received hop count and the zone's configured hop count, and the count is then decremented at each hop; 483 Too Many Hops results if it reaches 0 before the destination 49. VCS zone hop count defaults to 15, and Cisco recommends setting it to 70 when crossing external cloud or internet networks 48. Cisco cautions that elevated hop counts increase loop exposure and advises enabling call loop detection 47.

On Cisco Expressway X15.2, hop counts range from 1 to 255 (default 15), decrement by 1 per forward, set the outgoing SIP Max-Forwards header, and end call searches if reduced to 0 20. Expressway terminates dial plan alias loops with a "policy loop detected" error 22, and Cisco advises configuring Call loop detection mode to On to stop unnecessary search circulation 21.

Microsoft Teams Direct Routing

Microsoft's Direct Routing SIP guidance specifies History-Info for loop prevention during call forwarding 44. Direct Routing preserves inbound History-Info and generates outbound History-Info only when the trunk parameter ForwardCallHistory is enabled 43. Direct Routing proxies inject History-Info for call forwarding and simultaneous ring, but omit it for call transfers 45. When a Teams user forwards a PSTN call, Direct Routing issues a 181 Call Is Being Forwarded provisional response to the caller and appends a cause parameter to the Request-URI of the forwarded INVITE 40. Direct Routing documentation references RFC 4244 for History-Info even though RFC 7044 obsoleted it in February 2014 42. If an SBC triggers multiple missed call alerts for a single declined call, Microsoft identifies SBC or PSTN retry behaviors as misconfigured and notes the SBC must cease retries on receiving a 603 response 41.

See also

Applicability

RFC 3261 requires a SIP UAC to insert a Max-Forwards header field with an initial value of 70 into each originated request, and proxy loop detection inspects Via headers to respond 482 46​1. RFC 5393 normatively updates RFC 3261 to address amplification vulnerabilities 38. RFC 7044 defines the SIP History-Info header and obsoletes RFC 4244 25. RFC 7332 requires every type of SIP B2BUA to copy and decrement received Max-Forwards values 4. Cisco Unified CM forwarding limits apply to Release 15 and SUs 14. Cisco Expressway dial plan and hop counts apply to release X15.2 20. Cisco IOS max-forwards applies from 12.1(3)T onward, with 70 default behavior introduced in 12.3(8)T and voice class tenant support added in 15.6(2)T and IOS XE Denali 16.3.1 29​30​28.

What remains uncertain

Whether Microsoft Teams Direct Routing supports alternative loop prevention headers when ForwardCallHistory is disabled is not covered by the sources below. The exact method Unified CM uses to determine loop breakout paths during active call processing is not covered by the sources below.

See also

Referenced by

Sources

  1. 1
    RFC 3261 gives proxies an optional loop-detection check that inspects Via header values (sent-by plus branch parameter) and, on detecting a loop, responds 482 (Loop Detected).
    RFC 3261 — SIP: Session Initiation Protocol · Section 16.3 Request Validation, item 4 (Optional Loop Detection check); Section 21.4.20 482 Loop Detected · Checked 2026-09-25
  2. 2
    The SIP response code 483 Too Many Hops means that the server received a request whose Max-Forwards value was zero; 482 Loop Detected means that the server detected a loop.
    RFC 3261 — SIP: Session Initiation Protocol · Section 21.4.20 482 Loop Detected; Section 21.4.21 483 Too Many Hops · Checked 2026-09-25
  3. 3
    RFC 7332 requires B2BUAs to check the received Max-Forwards value and to reject or respond to the request, rather than pass it on, when the value is zero.
    RFC 7332: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) · Section 3 B2BUA Behavior · Checked 2026-09-25
  4. 4
    RFC 7332 requires every type of SIP B2BUA to copy the Max-Forwards value it receives on its UAS side into the requests it generates on its UAC side, and to decrement that value.
    RFC 7332: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) · Section 3 B2BUA Behavior, Max-Forwards requirement · Checked 2026-09-25
  5. 5
    Under RFC 7332, when a B2BUA generates a request on its UAC side and the received request had no Max-Forwards header field, the B2BUA must create one; the recommended value is 70.
    RFC 7332: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) · Section 3 B2BUA Behavior · Checked 2026-09-25
  6. 6
    If an SBC or PBX acting as a B2BUA starts each outgoing leg at a fresh Max-Forwards value instead of copying and decrementing the received value, a call looping between that device and a carrier never runs Max-Forwards down to zero and is not stopped by a 483.inferred
    RFC 7332: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) · Section 3 B2BUA Behavior (reasoning from the copy-and-decrement requirement) · Checked 2026-09-25
  7. 7
    RFC 7332 recommends that B2BUAs implement the Via-based loop-detection mechanism that RFC 5393 defines for proxies, and requires them to copy any received Max-Breadth header field to the requests they generate.
    RFC 7332: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) · Section 3 B2BUA Behavior (Via loop detection; Max-Breadth) · Checked 2026-09-25
  8. 8
    Binding each CUBE inbound dial-peer to a dial-peer group that excludes the trunk the call arrived on is a way to stop a carrier-to-CUBE call from being routed back out to the same carrier.inferred
    Understand IOS and IOS XE Call Routing · Dial-Peer Groups section (applied reasoning) · Checked 2026-09-25
  9. 9
    Unified CM does not prevent a CFA loop when Call Forward All is activated through Unified CM Administration or the Self Care Portal instead of from the phone.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · Call Forward All Loop Prevention (restriction) · Checked 2026-09-25
  10. 10
    Unified CM supports CFA loop breakout, so an existing CFA loop does not break call processing: the call runs through the forwarding chain and breaks out of the loop.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · Call Forward All Loop Breakout · Checked 2026-09-25
  11. 11
    With CFA Destination Override enabled, Unified CM ignores the CFA destination when it matches the calling party number, so the forwarding target calling the initiator rings the initiator instead of forwarding back.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · CFA Destination Override · Checked 2026-09-25
  12. 12
    Unified CM prevents Call Forward All activation from the phone when the new destination would complete a CFA loop, for example 1000 forwarding to 1001 when 1001, 1002 and 1003 already forward all calls in a chain back to 1000.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · Call Forward All Loop Prevention · Checked 2026-09-25
  13. 13
    Unified CM's hop-count-based CFA activation block applies only when CFA is activated from the phone, the chain exceeds Forward Maximum Hop Count, and every phone in the chain uses CFA rather than CFB, CFNA or another forwarding type.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · Call Forward All Loop Prevention / Forward Maximum Hop Count conditions · Checked 2026-09-25
  14. 14
    In Unified CM 15, the Forward Maximum Hop Count service parameter (System > Service Parameters) sets the maximum number of times a single call can be forwarded or diverted.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · Call Forwarding Configuration Task Flow / Call Forwarding Fields: Forward Maximum Hop Count · Checked 2026-09-25
  15. 15
    When a call in Unified CM 15 reaches the forwarding maximum hop count, it goes to the original called party's MAP target if one is configured; otherwise it is rejected and the caller hears reorder tone.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · Call Forwarding chapter, paragraph on reaching the maximum hop count · Checked 2026-09-25
  16. 16
    For incoming QSIG calls, Unified CM caps diversions at 15 regardless of a higher Forward Maximum Hop Count, and Cisco recommends setting the parameter to 15 when QSIG trunks are configured.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · Forward Maximum Hop Count (QSIG note) · Checked 2026-09-25
  17. 17
    Unified CM has a separate service parameter, Max Forward UnRegistered Hops to DN, that sets how many forward-unregistered hops a directory number may have at the same time.
    Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding · Call Forward Unregistered / Max Forward UnRegistered Hops to DN · Checked 2026-09-25
  18. 18
    The Diversion header has a counter parameter, and RFC 5806 says the ISUP Redirection Counter should be set to the sum of the counters of all Diversion headers in the SIP message.
    RFC 5806: Diversion Indication in SIP · Section 4 (syntax, counter parameter); Section 9.2.4 (ISUP mapping) · Checked 2026-09-25
  19. 19
    The SIP Diversion header is documented in RFC 5806 (March 2010) with Historic status, and the IESG note there points to History-Info (RFC 4244) as the standard mechanism that was chosen instead.
    RFC 5806: Diversion Indication in SIP · IESG Note (page 2); status header · Checked 2026-09-25
  20. 20
    In Expressway X15.2, hop counts can be set from 1 to 255 (default 15), are decremented by one on each forward, set the Max-Forwards field for SIP, and the search fails when the count reaches zero.
    Cisco Expressway Administrator Guide (X15.2) - Dial Plan and Call Processing · Hop Counts section · Checked 2026-09-25
  21. 21
    The Expressway X15.2 guide advises setting Call loop detection mode to On so that search requests do not circulate unnecessarily when hop counts are higher than needed.
    Cisco Expressway Administrator Guide (X15.2) - Dial Plan and Call Processing · Configuring Call Routing and Signaling: Call loop detection mode · Checked 2026-09-25
  22. 22
    Expressway detects circular references in its dial plan (an alias transformed and later transformed back) and ends that search branch with a 'policy loop detected' error.
    Cisco Expressway Administrator Guide (X15.2) - Dial Plan and Call Processing · Call routing process / circular references · Checked 2026-09-25
  23. 23
    Under RFC 5393, a proxy that forks a request to more than one destination must ensure the request is not looping through it; Via-based loop detection is recommended, but other mechanisms are allowed.
    RFC 5393: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies · Section 4 (Normative changes to RFC 3261), loop-detection requirement · Checked 2026-09-25
  24. 24
    Each History-Info entry carries a mandatory index parameter, written as dot-separated integers such as 1.1.2, that records the chronological order and branching of retargeting hops.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 10.3 (index parameter) · Checked 2026-09-25
  25. 25
    RFC 7044 (February 2014) defines the SIP History-Info header, which records how and why a request reached its target through retargeting such as forwarding, and it obsoletes RFC 4244.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Abstract; Section 1 Introduction · Checked 2026-09-25
  26. 26
    History-Info entries can carry a Reason header with the SIP response code that caused the retargeting, for example 302 for unconditional forwarding, 486 for busy, 408 for timeout or 480 for temporarily unavailable.
    RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information · Section 10.2 (Reason header in hi-entries) · Checked 2026-09-25
  27. 27
    On Cisco IOS and IOS XE gateways, dial-peer groups can pin the exact outbound dial-peer according to the inbound dial-peer that matched, which constrains where a call received on a trunk can be sent.
    Understand IOS and IOS XE Call Routing · Dial-Peer Groups section · Checked 2026-09-25
  28. 28
    The IOS max-forwards command got a larger range and a higher default in release 12.3(8)T to comply with RFC 3261; it was first introduced in 12.1(3)T.
    Cisco IOS Voice Command Reference - K through R - map q850-cause through mgcp package-capability (max-forwards) · max-forwards command entry: Command History · Checked 2026-09-25
  29. 29
    On Cisco IOS and IOS XE voice gateways and CUBE, the max-forwards command in sip-ua configuration mode sets the SIP maximum hop count, with a range of 1 to 70 and a default of 70.
    Cisco IOS Voice Command Reference - K through R - map q850-cause through mgcp package-capability (max-forwards) · max-forwards command entry: Syntax Description; Command Default · Checked 2026-09-25
  30. 30
    The IOS max-forwards command is also available in voice class tenant mode, and its system keyword, added in IOS 15.6(2)T and IOS XE Denali 16.3.1, makes the tenant fall back to the global setting.
    Cisco IOS Voice Command Reference - K through R - map q850-cause through mgcp package-capability (max-forwards) · max-forwards command entry: Command Modes; Command History; Usage Guidelines · Checked 2026-09-25
  31. 31
    IOS lists max-redirects, which sets the maximum number of redirects allowed, as a command related to max-forwards.
    Cisco IOS Voice Command Reference - K through R - map q850-cause through mgcp package-capability (max-forwards) · max-forwards command entry: Related Commands · Checked 2026-09-25
  32. 32
    Cisco's IOS/IOS XE call-routing technote uses debug voip ccapi inout and debug ccsip messages to see dial-peer matching and SIP signalling for a call.
    Understand IOS and IOS XE Call Routing · Troubleshooting / debug references · Checked 2026-09-25
  33. 33
    RFC 5393 defines a Max-Breadth header field that limits concurrent forked branches for a request, with a recommended initial value of 60.
    RFC 5393: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies · Section 5 (Max-Breadth) · Checked 2026-09-25
  34. 34
    The SIP Max-Forwards header field limits the number of hops a request can make toward its destination and holds an integer that is decremented by one at each hop.
    RFC 3261 — SIP: Session Initiation Protocol · Section 20.22 Max-Forwards · Checked 2026-09-25
  35. 35
    A SIP proxy that receives a request whose Max-Forwards value is zero must not forward it and returns 483 (Too Many Hops), except that it may answer an OPTIONS request addressed to itself.
    RFC 3261 — SIP: Session Initiation Protocol · Section 16.3 Request Validation, item 3 (Max-Forwards check) · Checked 2026-09-25
  36. 36
    When forwarding a request, a SIP proxy decrements Max-Forwards by one, and if the request carries no Max-Forwards header field the proxy adds one with the value 70.
    RFC 3261 — SIP: Session Initiation Protocol · Section 16.6 Request Forwarding, step 3 (Max-Forwards) · Checked 2026-09-25
  37. 37
    RFC 5393 does not change RFC 3261's recommended initial Max-Forwards value of 70; it mitigates the amplification that this depth allows by adding loop-detection and Max-Breadth requirements.
    RFC 5393: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies · Section 3 (Vulnerability) and Section 4 discussion of Max-Forwards · Checked 2026-09-25
  38. 38
    RFC 5393 (December 2008, Standards Track) normatively updates RFC 3261 to fix an amplification vulnerability in which forking proxies without loop detection turn a few requests into very large amounts of proxy-to-proxy traffic.
    RFC 5393: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies · Abstract; Section 3 (Vulnerability) · Checked 2026-09-25
  39. 39
    RFC 3261 distinguishes a spiral from a loop: a request that returns to the same proxy with a different Request-URI (for example after call forwarding) is a spiral and is legitimate, not a loop.
    RFC 3261 — SIP: Session Initiation Protocol · Section 16.3 Request Validation, item 4 (spiral discussion) · Checked 2026-09-25
  40. 40
    When a Teams user forwards a call from a PSTN caller, the Direct Routing SIP proxy sends the caller a 181 Call Is Being Forwarded provisional response, and the forwarded INVITE's Request-URI carries a cause parameter.
    Teams Phone System Direct Routing: SIP protocol · Call forwarding section, bullets · Checked 2026-09-25
  41. 41
    Microsoft says that several missed calls for one declined call mean the SBC or PSTN trunk provider's retry mechanism is misconfigured, and the SBC must be reconfigured to stop retrying on a 603 response.
    Teams Phone System Direct Routing: SIP protocol · Handling retries (603 response) · Checked 2026-09-25
  42. 42
    Microsoft's Direct Routing SIP article cites RFC 4244 for History-Info, although RFC 7044 obsoleted RFC 4244 in February 2014.
    Teams Phone System Direct Routing: SIP protocol · History-Info header section, first paragraph · Checked 2026-09-25
  43. 43
    In Direct Routing, the trunk's ForwardCallHistory parameter controls whether History-Info is populated, and inbound History-Info is preserved only when ForwardCallHistory is enabled.
    Teams Phone System Direct Routing: SIP protocol · Call forwarding section; History-Info header section · Checked 2026-09-25
  44. 44
    Microsoft's Direct Routing SIP guidance says the History-Info header should be used for loop prevention in call-forwarding scenarios.
    Teams Phone System Direct Routing: SIP protocol · Call forwarding section, final bullet · Checked 2026-09-25
  45. 45
    The Direct Routing SIP proxy adds History-Info for simultaneous ring and call forwarding but not for call transfer.
    Teams Phone System Direct Routing: SIP protocol · History-Info header section, bullets · Checked 2026-09-25
  46. 46
    RFC 3261 requires a SIP UAC to insert a Max-Forwards header field into each request it originates, with an initial value that should be 70.
    RFC 3261 — SIP: Session Initiation Protocol · Section 8.1.1.6 Max-Forwards · Checked 2026-09-25
  47. 47
    Cisco warns that setting VCS/Expressway hop counts higher than necessary risks loops, and advises turning on call loop detection.
    VCS Max-Forwards Value Increase for Error Code 483 Resolution · Solution (caution note) · Checked 2026-09-25
  48. 48
    The default zone hop count on Cisco VCS/Expressway is 15, and Cisco recommends 70 for zones whose traffic crosses unknown networks such as cloud or internet services.
    VCS Max-Forwards Value Increase for Error Code 483 Resolution · Solution (hop count default and recommendation) · Checked 2026-09-25
  49. 49
    On Cisco VCS, a request forwarded through a zone uses the lower of its received hop count and the zone's configured hop count, and the count is then decremented at each hop; 483 Too Many Hops results if it reaches zero before the destination.
    VCS Max-Forwards Value Increase for Error Code 483 Resolution · Problem; Solution · Checked 2026-09-25

Documents

tier 1 standards and regulators

RFC 3261 — SIP: Session Initiation Protocol

IETF / RFC Editor · 2002-06 · accessed 2026-09-04

tier 1 standards and regulators

RFC 5393: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies

IETF / RFC Editor · 2008-12-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 5806: Diversion Indication in SIP

IETF / RFC Editor · 2010-03-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 7044: An Extension to the Session Initiation Protocol (SIP) for Request History Information

IETF / RFC Editor · 2014-02-01 · accessed 2026-09-25

tier 1 standards and regulators

RFC 7332: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)

IETF / RFC Editor · 2014-08-01 · accessed 2026-09-25

tier 2 current vendor documentation

Cisco Expressway Administrator Guide (X15.2) - Dial Plan and Call Processing

Cisco Systems · accessed 2026-09-25

tier 2 current vendor documentation

Cisco IOS Voice Command Reference - K through R - map q850-cause through mgcp package-capability (max-forwards)

Cisco Systems · 2024-12-21 · accessed 2026-09-25

tier 2 current vendor documentation

Feature Configuration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Forwarding

Cisco Systems · 2026-09-16 · accessed 2026-09-24

tier 2 current vendor documentation

Teams Phone System Direct Routing: SIP protocol

Microsoft · 2026-08-21 · accessed 2026-09-23

tier 2 current vendor documentation

Understand IOS and IOS XE Call Routing

Cisco Systems · 2026-04-28 · accessed 2026-09-24

tier 2 current vendor documentation

VCS Max-Forwards Value Increase for Error Code 483 Resolution

Cisco Systems · 2015-09-11 · accessed 2026-09-25

Cite this page

APA

WarmTransfer. (2026, September 25). SIP call forwarding and routing loops. WarmTransfer. https://warmtransfer.net/knowledge/sip-forwarding-loops

BibTeX

@misc{warmtransfer-sip-forwarding-loops,
  title  = {SIP call forwarding and routing loops},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sip-forwarding-loops},
  note   = {Verified 2026-09-25}
}