IMS

  

 

 

 

Transport Selection and Port Number Determination

 

Recently I have been experiencing some of the issues while testing IMS which is related to Transport Selection (TCP/UDP selection) or Port Number setting.

I haven't got clear understandings of all the details behind these issues that can be stated in this page, but I thought it would be good time to start posting something. This page will be updated frequently and revised/corrected as well as I find more.

Testing IMS (IP Multimedia Subsystem) often feels like a puzzle where the pieces only fit together if the signaling protocols are perfectly aligned. Since you're diving into Transport Selection and Port Determination, you're essentially looking at how SIP (Session Initiation Protocol) decides which "road" to take and which "gate" to enter.

Determination of TCP/UDP

SIP transport selection in IMS determines how signaling messages are delivered between network elements such as the UE and the CSCF. The SIP stack does not always use a single fixed transport. Instead, the transport can be determined by configuration, message size, or explicit transport parameters contained in SIP headers. In some situations the protocol may start with one transport and later switch to another if certain conditions are met. Because of this behavior, understanding how SIP selects its transport and destination port is important when analyzing IMS signaling and troubleshooting session establishment problems.

Case 1 : Static Transport Selection

Case 1 represents the simplest SIP transport behavior. The transport is predetermined before signaling starts, so the SIP stack does not examine message size or apply any dynamic switching logic. It simply uses the configured transport for every message in that flow. In practice, this means the signaling path is more predictable, but any mismatch in transport type, port setting, or connection state can immediately cause registration or session setup to fail.

 

High level criterial to go with this option are

  • TCP Regardless
    • Used when reliability or security is required.
    • Common when SIP runs over TLS because TLS requires a TCP transport.
    • Often used in VoWiFi deployments where the public internet may have unpredictable MTU sizes.
    • Frequently used by services such as messaging or presence (e.g., RCS) where SIP bodies tend to be large.
  • UDP Regardless
    • Used when minimizing signaling overhead is important.
    • Common in early or simple VoLTE deployments where the network is tightly controlled.
    • Often used inside the IMS core network where packet loss is very low and throughput is prioritized.
  • Testing Considerations
    •   TCP Connection State
      • TCP requires a valid connection before SIP signaling can be exchanged.
      • If the server closes the connection due to inactivity, the next request may fail.
      • Periodic keep-alive messages (often double CRLF) are typically used to maintain the connection.
    •   Port Configuration
      • TCP signaling may use port 5060 for plain SIP or 5061 for SIP over TLS.
      • A common failure occurs when the UE attempts TCP on port 5060 while the server expects TLS on port 5061.
      • Both the transport type and port number must match the network configuration.

 

Example 01 :

This example shows a real IMS registration flow in which both transport selection and port determination are clearly visible under IPsec protection. In this case, the signaling path is not chosen dynamically during the exchange. The use of TCP is explicitly indicated by the SIP headers, and the port numbers are negotiated through the security-related headers so that both the UE and the P-CSCF know exactly which protected ports to use for sending and receiving SIP messages. This makes the trace a very good reference for understanding how reliable transport and IPsec-related port mapping work together in practical IMS signaling.

    You would notice

    • (A) matches (1)

    (A) Transmission Control Protocol, (B) Src Port: 50000 , (C) Dst Port: 55062 ,

      REGISTER sip:one.att.net SIP/2.0

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:(D)50001;

               branch=z9hG4bK44ccabd6a7f33104360e9ae78ce1ac0d;rport

        Max-Forwards: 70

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(E)50001;(F) transport=tcp>;

                    +g.3gpp.smsip;

                    +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

                    +sip.instance="<urn:gsma:imei:00440224-264925-0>"

        To: <sip:310410123456789@one.att.net>

        From: <sip:310410123456789@one.att.net>;tag=4887461765a4b2fc-d90ef734.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 2 REGISTER

        Expires: 600000

        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

        User-Agent: IM-client/OMA1.0 TEST-IMS

        Authorization: Digest username="310410123456789@private.att.net", realm="one.att.net",

          nonce="1XcMbTY+MMNkpAePG/jtOm4yOzbFNdVV1XYObjNi45E=", uri="sip:one.att.net", response="7a87c22410c409ffef55ea37b41bfe4c",

          algorithm=AKAv1-MD5,

          cnonce="b4972c8ee817300a7ff36ed1cbd59be", opaque="09e88aef2....", qop=auth, nc=00000001

        Security-Verify: ipsec-3gpp; ealg=null; alg=hmac-sha-1-96; spi-c=98765431; spi-s=87654321;

          (G)port-c=55063;

          (H)port-s=55062;

          q=0.9,ipsec-3gpp; ealg=null; alg=hmac-md5-96; spi-c=98765431; spi-s=87654321;

          (I)port-c=55063;

          (J)port-s=55062;

          q=0.7

        P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=31041000040000004

        Supported: sec-agree, path

        Proxy-Require: sec-agree

        Security-Client: ipsec-3gpp; ealg=aes-cbc;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (K)port-c=50000;

          (L)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=aes-cbc; alg=hmac-md5-96; spi-c=41064354; spi-s=34933966;

          (M)port-c=50000;

          (N)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=des-ede3-cbc;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (O)port-c=50000;

          (P)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=des-ede3-cbc; alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966;

          (Q)port-c=50000;

          (R)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=null; alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (S)port-c=50000;

          (T)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=null; alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966;

          (U)port-c=50000;

          (V)port-s=50001;

          prot=esp; mod=trans

        Require: sec-agree

        Content-Length: 0

 

    (1)Transmission Control Protocol, (2)Src Port: 55062, (3)Dst Port: 50000, Seq: 1, Ack: 2279, Len: 655

      SIP/2.0 200 OK

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:(4)50001;

              branch=z9hG4bK44ccabd6a7f33104360e9ae78ce1ac0d;rport

        To: <sip:310410123456789@one.att.net>; tag=ATL2604_d9bc654771cd

        From: <sip:310410123456789@one.att.net>;tag=4887461765a4b2fc-d90ef734.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 2 REGISTER

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(5)50001;(6)transport=tcp>; expires=1200

        P-Associated-URI: <tel:+14251234567>

        P-Associated-URI: <sip:+14251234567@one.att.net>

        Service-Route: <sip:scscf.anyims.test.3gpp.com;lr>

        Path: <sip:[fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7];lr>

        Content-Length: 0

This is the bulleted summary of this example

  • Overall Meaning
    • This trace shows a real IMS registration over IPsec.
    • It clearly illustrates both transport selection and port determination.
    • The transport and port usage are explicitly controlled by SIP security-related headers.
  • Transport Selection
    • The signaling uses TCP.
    • The main reason is the ;transport=tcp parameter in the Contact header.
    • This means the UE and the P-CSCF are fixed to TCP from the beginning.
    • The transport is not chosen dynamically based on packet size.
    • The presence of security negotiation such as Proxy-Require: sec-agree also aligns with this behavior.
  • Why TCP is Important Here
    • TCP provides reliable delivery for SIP signaling.
    • In many IMS carrier implementations, TCP is commonly used when IPsec security association setup is involved.
    • This makes the signaling path more stable during security negotiation.
  • UE Port Information
    • The UE proposes its protected ports in the Security-Client header.
    • port-c=50000
      • This is the protected client port.
      • The UE expects to receive SIP requests on this port.
    • port-s=50001
      • This is the protected server port from the UE perspective.
      • The UE sends SIP requests using this port.
    • These values are also reflected in headers such as Via and Contact.
  • Network Port Information
    • The P-CSCF responds with its own protected ports in Security-Server or Security-Verify related information.
    • port-c=55063
      • This is the P-CSCF protected client port.
    • port-s=55062
      • This is the P-CSCF protected server port.
    • These values define how the network side sends and receives protected SIP signaling.
  • Port Mapping in the Response
    • In the response packet, the network source port is 55062.
    • This matches the network port-s value.
    • The destination port is 50000.
    • This matches the UE port-c value.
    • This confirms that the protected port mapping is being applied correctly.
  • Key Takeaway
    • The transport is fixed by ;transport=tcp.
    • The protected port numbers are negotiated through the SIP security headers.
    • Both sides must use the negotiated ports consistently.
    • This is a good example of how IMS registration works when SIP signaling is protected by IPsec.

Case 2 : Switch Over Logic (The 1300-Byte Rule)

This case shows the dynamic side of SIP transport selection. In this case, the transport is not fixed by configuration from the beginning. Instead, the SIP stack checks the message size at the time of transmission and decides whether UDP is still appropriate. When the message becomes large enough to approach the MTU limit, the stack switches to TCP to avoid fragmentation and improve delivery reliability. This is why this is important in IMS testing, because the transport can change automatically depending on the actual payload size.

Followings are the bulleted details :

  • Overall Meaning
    • Case 2 shows dynamic transport selection.
    • The SIP stack does not simply follow a fixed transport rule.
    • It checks the message size at the time of transmission.
    • If the message is too large for safe UDP delivery, it switches to TCP.
  • 1300-Byte Rule
    • This behavior is defined in RFC 3261 Section 18.1.1.
    • The purpose is to avoid IP fragmentation.
    • Fragmented SIP packets are often dropped by firewalls, NAT devices, or middleboxes.
    • A common practical threshold is 1300 bytes.
    • This comes from the common MTU of 1500 bytes, leaving about 200 bytes of margin.
  • How the Rule Works
    • If the SIP message is small, the stack may use UDP.
    • If the message approaches the MTU limit, the stack should use TCP instead.
    • This decision is made dynamically for the actual message being sent.
    • As a result, the same UE may use different transports for different SIP messages.
  • Case 2 Left Scenario
    • The UA sends a large SIP request.
    • A typical example is an INVITE carrying a large SDP body.
    • Because the message exceeds the safe UDP size, the UA opens a TCP connection.
    • The request is then sent over TCP.
    • The peer responds over the established TCP path.
  • Case 2 Right Scenario
    • The UA sends a large request using TCP.
    • The response is small.
    • In some cases, the network side may return that small response using UDP.
    • This creates an asymmetric transport scenario.
    • The request and response may not always use the same transport unless the transport is explicitly fixed.
  • Why This Matters in IMS Testing
    • The transport may change automatically depending on the payload size.
    • A SIP flow that worked with a small message may fail with a larger one.
    • The problem is often not in the SIP content itself.
    • The real issue is that the transport behavior has changed underneath.
  • Common Failure Points
    •   Fragmentation Problem
      • If a large message is still sent over UDP, it may be fragmented.
      • Many IMS nodes or security devices drop fragmented SIP packets.
    •   Firewall or NAT Mismatch
      • Some firewalls expect the response to return on the same protocol as the request.
      • If the request uses TCP and the response comes back on UDP, the response may be blocked.
    •   TCP Setup Delay
      • When TCP is selected, the sender must first complete the TCP three-way handshake.
      • This adds delay before the SIP message is actually sent.
      • If the network is slow or congested, the SIP transaction may time out.
  • Comparison with Case 1
    • Case 1 is based on configuration.
    • Case 2 is based on payload size.
    • In Case 1, the transport is fixed before signaling starts.
    • In Case 2, the transport is decided at runtime for each message.
    • A single device may show both behaviors depending on the situation.

 

Case 2a : Switch Over Logic (The 1300-Byte Rule)

This is with the same logic as the previous case. Just small differences in terms of packet size in Request and Response message.

 

The bulleted details with focus on the differece from Case 1 :

  • Key Difference from Previous Case
    • The request message is still sent using UDP because its size is smaller than 1300 bytes.
    • The transport decision changes only when the response message size exceeds the threshold.
    • This means the transport can switch during the response phase even if the request used UDP.
  • Transport Behavior Change
    • If the response message size is greater than 1300 bytes, the sender switches to TCP.
    • If the response message size remains smaller than 1300 bytes, the sender continues using UDP.
    • This creates two possible outcomes depending on the response payload size.
  • Left Scenario in the Diagram
    • The request is small, so it is transmitted using UDP.
    • The response becomes large and exceeds the 1300-byte threshold.
    • The responder switches the transport to TCP to avoid fragmentation.
  • Right Scenario in the Diagram
    • The request is small and sent using UDP.
    • The response is also small and remains below the threshold.
    • The response continues to use UDP, so no transport change occurs.
  • Main Point
    • The difference from the previous case is that the transport change is triggered by the response size, not the request size.
    • This means a SIP transaction may start with UDP but the response may return using TCP if the response payload becomes large.

Case 3 : The transport Attribute

This case represents the most explicit form of SIP transport selection. In this situation, the transport is not determined by configuration or packet size. Instead, it is directly specified within the SIP signaling itself through the transport parameter in the Contact URI. Once this parameter is included during registration, the network records it as part of the UE’s binding and uses the specified transport for future requests toward that UE, regardless of message size.

 

Bulleted details for this case are :

  • Transport Attribute
    • The key mechanism is the transport parameter in the Contact URI.
    • A typical example is ;transport=tcp.
    • This parameter tells the network which transport should be used to reach the UE.
    • It acts as an explicit instruction rather than a dynamic decision.
  • How It Works During Registration
    • During REGISTER, the UE provides its Contact URI to the network.
    • This Contact URI becomes part of the UE’s binding in the registrar.
    • If the Contact URI includes ;transport=tcp, the P-CSCF stores that requirement.
    • Later, when the network sends a request toward the UE, it uses the stored transport information.
  • Why Packet Size No Longer Matters
    • In this case, the transport is already fixed by the Contact URI.
    • The network does not need to re-evaluate the SIP message size for transport choice.
    • Even a small incoming request may still be sent over TCP if the binding says TCP.
    • This is different from the 1300-byte rule cases where size drives the decision.
  • Why This is Important
    • It allows the UE to control how it should be contacted for future mobile-terminated requests.
    • It makes the signaling path more predictable from a routing perspective.
    • This behavior is especially common in environments where reliable or secure transport is preferred.
  • Common Deployment Context
    • This case is often seen in VoWiFi scenarios.
    • It is also common in IPsec-protected IMS environments.
    • In these cases, TCP is often preferred for stable and reliable signaling delivery.
  • Common Failure Points
    •   Unsupported Listener
      • The UE may request ;transport=tcp, but the P-CSCF listener may only support UDP.
      • In that case, incoming requests may fail even if registration appears normal.
    •   TCP Connection State
      • If TCP is forced, the TCP path must remain usable.
      • If the connection closes because of inactivity, the UE may become unreachable for incoming requests.
    •   NAT or Firewall Timeout
      • If the UE is behind NAT or a firewall, idle TCP sessions may be removed before registration expires.
      • This can create a situation where the UE is still registered but no longer reachable.
    •   Missing Transport Attribute
      • If the Contact URI does not include a transport parameter, the stack usually falls back to the default behavior.
      • In many traditional cases, that default is UDP.
      • If the test environment expects UDP but the network prefers TCP, transport mismatch issues may appear.
  • Main Point
    • This case is controlled by an explicit SIP binding rule.
    • The Contact URI tells the network how to reach the UE.
    • Once stored, that rule overrides message-size-based transport decisions for future requests.

 

Example 01 :

This example shows how the transport preference declared during IMS registration is later applied to an incoming mobile-terminated call. The UE first tells the network how it wants to be reached by including the transport type and port information in its registration-related headers. Later, when the network sends an incoming INVITE, it follows that stored binding and uses the same transport and destination port that the UE previously requested. This makes the trace a clear example of how a Contact header attribute in REGISTER directly controls the behavior of a later MT SIP request.

    You would notice

    • (E) matches (1)

    Transmission Control Protocol, (A) Src Port: 50000 , (B) Dst Port: 55062 , Seq: 2264924161, Ack: 354, Len: 312

      REGISTER sip:one.att.net SIP/2.0

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:(C)50001;

               branch=z9hG4bK44ccabd6a7f33104360e9ae78ce1ac0d;rport

        Max-Forwards: 70

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(D)50001;(E) transport=tcp>;

                    +g.3gpp.smsip;

                    +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

                    +sip.instance="<urn:gsma:imei:00440224-264925-0>"

        To: <sip:310410123456789@one.att.net>

        From: <sip:310410123456789@one.att.net>;tag=4887461765a4b2fc-d90ef734.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 2 REGISTER

        Expires: 600000

        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

        User-Agent: IM-client/OMA1.0 TEST-IMS

        Authorization: Digest username="310410123456789@private.att.net", realm="one.att.net",

          nonce="1XcMbTY+MMNkpAePG/jtOm4yOzbFNdVV1XYObjNi45E=", uri="sip:one.att.net", response="7a87c22410c409ffef55ea37b41bfe4c",

          algorithm=AKAv1-MD5,

          cnonce="b4972c8ee817300a7ff36ed1cbd59be", opaque="09e88aef2....", qop=auth, nc=00000001

        Security-Verify: ipsec-3gpp; ealg=null; alg=hmac-sha-1-96; spi-c=98765431; spi-s=87654321;

          (F)port-c=55063;

          (G)port-s=55062;

          q=0.9,ipsec-3gpp; ealg=null; alg=hmac-md5-96; spi-c=98765431; spi-s=87654321;

          (H)port-c=55063;

          (I)port-s=55062;

          q=0.7

        P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=31041000040000004

        Supported: sec-agree, path

        Proxy-Require: sec-agree

        Security-Client: ipsec-3gpp; ealg=aes-cbc;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (J)port-c=50000;

          (K)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=aes-cbc; alg=hmac-md5-96; spi-c=41064354; spi-s=34933966;

          (L)port-c=50000;

          (M)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=des-ede3-cbc;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (N)port-c=50000;

          (O)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=des-ede3-cbc; alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966;

          (P)port-c=50000;

          (Q)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=null; alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (R)port-c=50000;

          (S)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=null; alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966;

          (T)port-c=50000;

          (U)port-s=50001;

          prot=esp; mod=trans

        Require: sec-agree

        Content-Length: 0

 

    (1)Transmission Control Protocol, (2) Src Port: 55063, (3) Dst Port: 50001, Seq: 1302, Ack: 1, Len: 341

      INVITE sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(4)50001;(5)transport=tcp SIP/2.0

        Via: SIP/2.0/TCP [fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7]:(6)55062; branch=z9hG4bK62b4a2938807

        Via: SIP/2.0/TCP scscf.anyims.test.3gpp.com; branch=z9hG4bK74eddae782b9

        Max-Forwards: 69

        To: <tel:+14251234567>

        From: <sip:+18472733800@one.att.net;user=phone>; tag=ATL2604_06f4d629ece8

        Call-ID: 551fe04688e4

        CSeq: 1 INVITE

        Via: SIP/2.0/TCP caller.3gpp.org:6543;branch=z9hG4bK87ee715641bd

        Record-Route: <sip:scscf.anyims.test.3gpp.com;lr>

        Record-Route: <sip:[fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7]:(7)55062;lr>

        Supported: 100rel,precondition

        Allow: INVITE,ACK,CANCEL,BYE,UPDATE,PRACK,MESSAGE,REFER,NOTIFY

        P-Asserted-Identity: <sip:+18472733800@one.att.net;user=phone>

        P-Called-Party-ID: <tel:+14251234567>

        Contact: <sip:+18472733800@[3000:0:0:2::1]:(8)5160>;

          +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video

        P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

        Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video

        Accept: application/sdp, application/3gpp-ims+xml

        Content-Length: 486

        Content-Type: application/sdp

Bulleted details for this example are :

  • Overall Meaning
    • This example shows how the transport and port information declared during REGISTER are later reused for a mobile-terminated INVITE.
    • The UE first defines how it wants to be reached.
    • The network then applies that stored binding when sending the incoming SIP request.
    • This is a direct example of Case 4 behavior being enforced in a later call flow.
  • Registration Stage
    • During REGISTER, the UE includes its preferred transport information in the Contact header.
    • The key attribute is ;transport=tcp.
    • This tells the network that future requests toward this UE should use TCP.
    • The UE also provides its reachable signaling port in the Contact-related information.
    • In this example, that port is 50001.
  • IPsec-Related Port Information
    • Because the registration is protected with IPsec, the UE also signals protected port information in the security headers.
    • The UE defines its own protected port values so the P-CSCF knows where protected SIP traffic should be sent.
    • In this case, the UE-side protected destination for incoming signaling is aligned with port 50001.
    • This creates a clear rule for later incoming requests.
  • Incoming INVITE Stage
    • When the network later sends an INVITE toward the UE, it follows the stored registration binding.
    • The INVITE uses TCP, matching the UE’s previously declared transport.
    • The INVITE is sent to destination port 50001, matching the UE’s registered signaling port.
    • This shows that the network is not making a new transport decision at that time.
    • It is reusing the transport and port information learned during registration.
  • Transport Match
    • The UE requested ;transport=tcp during registration.
    • Later, the incoming INVITE is also sent over TCP.
    • This confirms that the Contact header attribute is being honored.
    • The message size of the INVITE is no longer the deciding factor.
    • The stored binding is the deciding factor.
  • Port Match
    • The UE had indicated 50001 as the port to be used for incoming signaling.
    • The incoming INVITE is delivered to Dst Port 50001.
    • This confirms that the network is following the registered contact information correctly.
  • Security Association Match
    • The source port used by the network in the INVITE is also consistent with the protected port information exchanged earlier.
    • This reflects that the IPsec-related security association parameters are being applied correctly.
    • It confirms that the registration phase and the later MT request phase are linked by the same stored security context.
  • Why This Matters
    • This trace shows a full closed loop.
    • The UE declares transport and port preference in REGISTER.
    • The network stores that information.
    • The network later uses the same information when sending the MT INVITE.
    • This is one of the clearest ways to verify that Contact binding and protected port handling are working correctly.
  • Common Failure Points
    •   TCP Listener Not Available
      • The UE may register with ;transport=tcp, but later fail to keep the TCP path available.
      • In that case, the network will still try TCP and the incoming call may fail.
    •   Firewall or NAT Timeout
      • The UE may still appear registered, but an intermediate firewall or NAT may have removed the TCP session.
      • Then the network cannot reach the UE even though the stored binding is correct.
    •   Port Mismatch
      • If the stored contact port and the actual reachable port do not match, the incoming INVITE will be sent to the wrong destination.
    •   Security Context Mismatch
      • If the protected port values exchanged during registration are not correctly maintained, the MT signaling path may fail even though the SIP headers appear normal.
  • Main Point
    • The REGISTER message creates the rule.
    • The incoming INVITE follows that rule.
    • This example clearly shows how a Contact header transport attribute and registered port information directly control a later mobile-terminated SIP request.

How UE knows which one to use for the first message ?

Can I reasonably conclude that, before sending the first SIP signaling message, the UE should have both UDP and TCP ready because it cannot know in advance which transport rule the other party will apply?

At the beginning of IMS registration, the UE does not normally open both UDP and TCP at the same time just to send the first SIP message. Instead, it selects the initial transport based on discovery results, local configuration, and access-specific behavior, and then adjusts later if the signaling or security negotiation requires a different transport. Once the registration and security context are established, however, the UE must remain ready to use the negotiated transport and port arrangement consistently for subsequent IMS signaling.

  • Overall Conclusion
    • It is understandable to think that the UE should open both UDP and TCP before sending the first SIP message.
    • However, in IMS and 3GPP behavior, the answer is more nuanced.
    • In general, the UE does not open both transports simultaneously for the very first SIP message.
    • Instead, it follows a discovery and negotiation process to decide the initial transport.
    • After registration or security negotiation, the UE must then stay ready to use the transport that was selected or negotiated.
  • Short Answer
    • Generally, no, the UE does not usually open both at the same time for the first message.
    • The UE normally starts with one transport.
    • That initial choice depends on discovery results, local policy, security negotiation, and access type.
    • Your intuition is still partly correct because the UE must eventually be able to handle the transport required by the network.
  • How the UE Decides the Initial Transport
    • Before sending the first SIP REGISTER, the UE uses several clues to determine which transport to start with.
    • The decision is not random.
    • It is usually guided by DNS discovery, IMS security procedures, and access-network-specific behavior.
  • P-CSCF Discovery by DNS
    • If the UE is configured with a P-CSCF domain name, it may perform DNS NAPTR or SRV lookup.
    • If the lookup result indicates _sip._udp, the UE starts with UDP.
    • If the result indicates _sip._tcp, the UE starts with TCP.
    • If both are available, the UE often starts with UDP for the initial REGISTER to reduce overhead, unless policy says otherwise.
  • IPsec Security Negotiation
    • In IPsec-based IMS registration, the initial transport choice can change during the authentication and security setup phase.
    • The UE proposes security algorithms and protected ports through Security-Client related headers.
    • The network may then require a different protected transport arrangement.
    • In that case, the UE may start with one transport and then switch for the later protected REGISTER.
    • This means the first and second REGISTER messages do not always use the same transport.
  • Access Technology Effect
    • The access network also strongly influences the initial transport behavior.
    • Over LTE/NR in VoLTE or VoNR, the UE often starts with UDP on port 5060.
    • Over Wi-Fi in VoWiFi, the UE often starts with TCP or a transport arrangement associated with IPsec and ePDG.
    • This is because Wi-Fi environments are more sensitive to fragmentation and variable MTU conditions.
  • Why It is Misleading to Say “Open Both”
    • Saying that the UE must open both can give the impression that both sockets are always actively established before the first SIP message.
    • That is usually not how IMS procedures work.
    • The UE usually selects one initial transport path first.
    • A better description is that the UE should be capable of supporting both, not that it must always open both immediately.
  • Why Readiness for Both Still Matters
    • Even if the UE starts with one transport, later signaling behavior may require support for the other.
    • A large SIP message may trigger transport switching based on size rules.
    • Security negotiation may lock the UE into TCP later.
    • An incoming response or request may arrive using a transport different from the one used initially.
    • So the UE must be able to adapt when required.
  • Testing Problems When Both Are Opened Without Need
    • Opening both transports in a test setup can create confusion.
    • One socket may remain unused while the other carries the actual signaling.
    • This can make debugging harder because idle or mismatched sockets may look like failures.
  • Typical Failure Point: Port Conflict
    • If a test tool binds both UDP and TCP on similar service ports, but the network expects only one of them, the unused path may appear to hang.
    • This can lead to timeout symptoms that are not caused by SIP itself.
    • The real issue may simply be that the wrong transport path was prepared or monitored.
  • Typical Failure Point: Case 3 Behavior
    • A UE may send an initial small SIP request using UDP.
    • Later, the peer may return a large response using TCP.
    • If the UE is not ready to accept TCP signaling when that happens, the transaction can fail.
    • In this sense, the UE does not have to start by opening both, but it must be dynamically able to support the required transport.
  • Main Takeaway
    • The UE does not usually open both simultaneously for the first SIP signaling message.
    • The UE typically starts with one transport selected through discovery or configuration.
    • But the UE must be prepared to support both transport behaviors across the full IMS procedure when signaling rules or negotiated security context require it.

Port Number

 

< Case 1 > ------------------------------------------------------------------------------------------------

 

 

 

Example 01 :

    You would notice

    • (B) matches (3)
    • (C) matches (2)

    (A) Transmission Control Protocol, (B) Src Port: 50000 , (C) Dst Port: 55062 ,

      REGISTER sip:one.att.net SIP/2.0

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:(D)50001;

               branch=z9hG4bK44ccabd6a7f33104360e9ae78ce1ac0d;rport

        Max-Forwards: 70

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(E)50001;(F) transport=tcp>;

                    +g.3gpp.smsip;

                    +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

                    +sip.instance="<urn:gsma:imei:00440224-264925-0>"

        To: <sip:310410123456789@one.att.net>

        From: <sip:310410123456789@one.att.net>;tag=4887461765a4b2fc-d90ef734.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 2 REGISTER

        Expires: 600000

        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

        User-Agent: IM-client/OMA1.0 TEST-IMS

        Authorization: Digest username="310410123456789@private.att.net", realm="one.att.net",

          nonce="1XcMbTY+MMNkpAePG/jtOm4yOzbFNdVV1XYObjNi45E=", uri="sip:one.att.net", response="7a87c22410c409ffef55ea37b41bfe4c",

          algorithm=AKAv1-MD5,

          cnonce="b4972c8ee817300a7ff36ed1cbd59be", opaque="09e88aef2....", qop=auth, nc=00000001

        Security-Verify: ipsec-3gpp; ealg=null; alg=hmac-sha-1-96; spi-c=98765431; spi-s=87654321;

          (G)port-c=55063;

          (H)port-s=55062;

          q=0.9,ipsec-3gpp; ealg=null; alg=hmac-md5-96; spi-c=98765431; spi-s=87654321;

          (I)port-c=55063;

          (J)port-s=55062;

          q=0.7

        P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=31041000040000004

        Supported: sec-agree, path

        Proxy-Require: sec-agree

        Security-Client: ipsec-3gpp; ealg=aes-cbc;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (K)port-c=50000;

          (L)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=aes-cbc; alg=hmac-md5-96; spi-c=41064354; spi-s=34933966;

          (M)port-c=50000;

          (N)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=des-ede3-cbc;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (O)port-c=50000;

          (P)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=des-ede3-cbc; alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966;

          (Q)port-c=50000;

          (R)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=null; alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966;

          (S)port-c=50000;

          (T)port-s=50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=null; alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966;

          (U)port-c=50000;

          (V)port-s=50001;

          prot=esp; mod=trans

        Require: sec-agree

        Content-Length: 0

 

    (1)Transmission Control Protocol, (2)Src Port: 55062, (3)Dst Port: 50000, Seq: 1, Ack: 2279, Len: 655

      SIP/2.0 200 OK

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:(4)50001;

              branch=z9hG4bK44ccabd6a7f33104360e9ae78ce1ac0d;rport

        To: <sip:310410123456789@one.att.net>; tag=ATL2604_d9bc654771cd

        From: <sip:310410123456789@one.att.net>;tag=4887461765a4b2fc-d90ef734.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 2 REGISTER

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(5)50001;(6)transport=tcp>; expires=1200

        P-Associated-URI: <tel:+14251234567>

        P-Associated-URI: <sip:+14251234567@one.att.net>

        Service-Route: <sip:scscf.anyims.test.3gpp.com;lr>

        Path: <sip:[fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7];lr>

        Content-Length: 0

 

 

< Case 2> ------------------------------------------------------------------------------------------------

 

 

 

< Case 3> ------------------------------------------------------------------------------------------------

 

 

Example 01 :

    You would notice followings :

    • (E) matches (3)
    • (2) is the random number allocated by CSCF

    (A)User Datagram Protocol, (B)Src Port: sip (5060), (C)Dst Port: sip (5060)

      REGISTER sip:test.3gpp.com SIP/2.0

        f: <sip:33333@test.3gpp.com>;tag=3034500338

        t: <sip:33333@test.3gpp.com>

        CSeq: 886930220 REGISTER

        i: 3034413867_2326928952@192.168.1.31

        v: SIP/2.0/UDP 192.168.1.31:5060;branch=z9hG4bK37595987

          Transport: TCP

          Sent-by Address: 192.168.1.31

          Sent-by port: (D)5060

          Max-Forwards: 70

        m: <sip:33333@192.168.1.31:5060>;

                +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

                +g.3gpp.smsip;video;+sip.instance="<urn:gsma:imei:35160200-126799-0>"

          Contact URI User Part: 33333

          Contact URI Host Part: 192.168.1.31

          Contact URI Host Port: (E)5060

        Route: <sip:192.168.1.2:5060;lr>

          Route URI Host Part: 192.168.1.2

          Route URI Host Port: (F)5060

          Route URI parameter: lr

        P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=0010100010000000

        Expires: 0

        l: 0

        Authorization: Digest uri="sip:test.3gpp.com",

          username="33333@test.3gpp.com",

          response="",realm="test.3gpp.com",

          nonce=""

        k: path

        Allow: INVITE,BYE,CANCEL,ACK,NOTIFY,UPDATE,REFER,PRACK,INFO,MESSAGE,OPTIONS

 

    (1)User Datagram Protocol, (2)Src Port: 51191 (51191), (3)Dst Port: sip (5060)

      INVITE sip:33333@192.168.1.31:(4)5060 SIP/2.0

        Via: SIP/2.0/UDP 192.168.1.2:(5)51191;branch=....;rport;transport=udp

        Via: SIP/2.0/UDP 192.168.1.2:(6)51182;branch=....;rport=51186

        Max-Forwards: 69

        Call-ID: 8bf2ef02e9db49d6b1d4e5b2091e64a9

        CSeq: 58001 INVITE

        To: <sip:33333@test.3gpp.com>

        From: <sip:1111@test.3gpp.com>;tag=1111111111

        Allow: INVITE, PRACK, UPDATE, ACK, BYE, CANCEL

        Supported: 100rel

        Supported: precondition

        Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";require;explicit

        User-Agent: Anritsu-VirtualUA/3923

        Content-Type: application/sdp

        Content-Length: 571

        Contact: <sip:1111@192.168.1.2:51182;transport=udp>

          Contact URI User Part: 1111

          Contact URI Host Part: 192.168.1.2

          Contact URI Host Port: (7)51182

          Contact URI parameter: transport=udp

        Privacy: none

        P-Asserted-Identity: <sip:1111@test.3gpp.com>

        Record-Route: <sip:192.168.1.2;lr>

 

 

< Case 4> ------------------------------------------------------------------------------------------------

 

 

Example 01 :

    Transmission Control Protocol, (A)Src Port: 64404 (64404), (B)Dst Port: sip (5060), ...

      REGISTER sip:one.att.net SIP/2.0

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:(C)5060;

          branch=z9hG4bKa904bdafbf4b82175d9ac6732fdd2fd6;rport

        Max-Forwards: 70

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(D)5060>;

          +g.3gpp.smsip;

          +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

          +sip.instance="<urn:gsma:imei:00440224-264925-0>"

        To: <sip:310410123456789@one.att.net>

        From: <sip:310410123456789@one.att.net>;tag=c5e5b838a178fe94-5185fd10.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 1 REGISTER

        Expires: 600000

        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

        User-Agent: IM-client/OMA1.0 TEST-IMS

        Authorization:

          Digest username="310410123456789@private.att.net",

          realm="one.att.net", nonce="",

          uri="sip:one.att.net",

          response=""

        Supported: sec-agree, path

        Proxy-Require: sec-agree

        Security-Client: ipsec-3gpp; ealg=aes-cbc; alg=hmac-sha-1-96;

          spi-c=41064354; spi-s=34933966; port-c=(E)50000; port-s=(F)50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=aes-cbc;

          alg=hmac-md5-96; spi-c=41064354; spi-s=34933966; port-c=(G)50000; port-s=(H)50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=des-ede3-cbc; alg=hmac-sha-1-96;

          spi-c=41064354; spi-s=34933966; port-c=(I)50000; port-s=(J)50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=des-ede3-cbc;

          alg=hmac-md5-96; spi-c=41064354; spi-s=34933966; port-c=(K)50000; port-s=(L)50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=null;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966; port-c=(M)50000; port-s=(O)50001;

          prot=esp; mod=trans, ipsec-3gpp; ealg=null;

          alg=hmac-md5-96; spi-c=41064354; spi-s=34933966; port-c=(P)50000; port-s=(Q)50001;

          prot=esp; mod=trans

        Require: sec-agree

        Content-Length: 0

 

    Transmission Control Protocol, (1)Src Port: sip (5060), (2)Dst Port: 64404 (64404), Seq: 1, Ack: 1683,

      SIP/2.0 401 Unauthorized

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:5060;branch=z9hG4bKa904bdafbf4b82175d9ac6732fdd2fd6;rport

        To: <sip:310410123456789@one.att.net>; tag=ATL2604_10c4d620f0c1

        From: <sip:310410123456789@one.att.net>;tag=c5e5b838a178fe94-5185fd10.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 1 REGISTER

        WWW-Authenticate:

          Digest realm="one.att.net",

          algorithm=AKAv1-MD5, q

          op="auth",

          nonce="1XcMbTY+MMNkpAePG/jtOm4yOzbFNdVV1XYObjNi45E=",

          opaque="09....."

        Security-Server:

          ipsec-3gpp; ealg=null;

          alg=hmac-sha-1-96;

          spi-c=98765431; spi-s=87654321; port-c=(3)55063; port-s=(4)55062;

          q=0.9

        Security-Server:

          ipsec-3gpp; ealg=null;

          alg=hmac-md5-96;

          spi-c=98765431; spi-s=87654321; port-c=(5)55063; port-s=(6)55062;

          q=0.7

        Content-Length: 0

 

    Transmission Control Protocol, (a)Src Port: 50000, (b)Dst Port: 55062, Seq: 1294, Ack: 1,

      REGISTER sip:one.att.net SIP/2.0

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:(c)50001;branch=z9h....;rport

        Max-Forwards: 70

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(d)50001;(e)transport=tcp>;

          +g.3gpp.smsip;

          +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

          +sip.instance="<urn:gsma:imei:00440224-264925-0>"

        To: <sip:310410123456789@one.att.net>

        From: <sip:310410123456789@one.att.net>;tag=4887461765a4b2fc-d90ef734.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 2 REGISTER

        Expires: 600000

        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

        User-Agent: IM-client/OMA1.0 TEST-IMS

        Authorization:

          Digest username="310410123456789@private.att.net",

          realm="one.att.net",

          nonce="1XcMbTY+MMNkpAePG/jtOm4yOzbFNdVV1XYObjNi45E=",

          uri="sip:one.att.net", r

          esponse="7a87c22410c409ffef55ea37b41bfe4c",

          algorithm=AKAv1-MD5,

          cnonce="b4972c8ee817300a7ff36ed1cbd59be", opaque="09e...",

          qop=auth,

          nc=00000001

        Security-Verify:

          ipsec-3gpp; ealg=null;

          alg=hmac-sha-1-96;

          spi-c=98765431; spi-s=87654321; port-c=(f)55063; port-s=(g)55062;

          q=0.9,

          ipsec-3gpp; ealg=null;

          alg=hmac-md5-96;

          spi-c=98765431; spi-s=87654321; port-c=(h)55063; port-s=(i)55062;

          q=0.7

        P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=31041000040000004

        Supported: sec-agree, path

        Proxy-Require: sec-agree

          Security-Client:

          ipsec-3gpp; ealg=aes-cbc;

          alg=hmac-sha-1-96;

          spi-c=41064354; spi-s=34933966; port-c=(j)50000; port-s=(k)50001; prot=esp;

          mod=trans, ipsec-3gpp;

          ealg=aes-cbc;

          alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966; port-c=(l)50000; port-s=(m)50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=des-ede3-cbc;

          alg=hmac-sha-1-96;

          spi-c=41064354; spi-s=34933966; port-c=(o)50000; port-s=(p)50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=des-ede3-cbc;

          alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966; port-c=(q)50000; port-s=(r)50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=null;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966; port-c=(s)50000; port-s=(t)50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=null;

          alg=hmac-md5-96; spi-c=41064354; spi-s=34933966; port-c=(u)50000; port-s=(v)50001; prot=esp; mod=trans

        Require: sec-agree

        Content-Length: 0

 

    Transmission Control Protocol, (i)Src Port: 55062 , (ii)Dst Port: 50000 , Seq: 1, Ack: 2279, Len: 655

      SIP/2.0 200 OK

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:50001;branch=z9h....;rport

        To: <sip:310410123456789@one.att.net>; tag=ATL2604_d9bc654771cd

        From: <sip:310410123456789@one.att.net>;tag=4887461765a4b2fc-d90ef734.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 2 REGISTER

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(iii)50001;(iv)transport=tcp>; expires=1200

        P-Associated-URI: <tel:+14251234567>

        P-Associated-URI: <sip:+14251234567@one.att.net>

        Service-Route: <sip:scscf.anyims.test.3gpp.com;lr>

        Path: <sip:[fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7];lr>

        Content-Length: 0

 

 

< Case 5> ------------------------------------------------------------------------------------------------

 

 

    Transmission Control Protocol, (a)Src Port: 50000, (b)Dst Port: 55062, Seq: 1294, Ack: 1,

      REGISTER sip:one.att.net SIP/2.0

        Via: SIP/2.0/TCP [3000::2:5547:21cb:7edf:9962]:(c)50001;branch=z9h....;rport

        Max-Forwards: 70

        Contact: <sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:(d)50001;(e)transport=tcp>;

          +g.3gpp.smsip;

          +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";

          +sip.instance="<urn:gsma:imei:00440224-264925-0>"

        To: <sip:310410123456789@one.att.net>

        From: <sip:310410123456789@one.att.net>;tag=4887461765a4b2fc-d90ef734.0

        Call-ID: 54df046e-10604c38-9f947b79@3000::2:5547:21cb:7edf:9962

        CSeq: 2 REGISTER

        Expires: 600000

        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

        User-Agent: IM-client/OMA1.0 TEST-IMS

        Authorization:

          Digest username="310410123456789@private.att.net",

          realm="one.att.net",

          nonce="1XcMbTY+MMNkpAePG/jtOm4yOzbFNdVV1XYObjNi45E=",

          uri="sip:one.att.net", r

          esponse="7a87c22410c409ffef55ea37b41bfe4c",

          algorithm=AKAv1-MD5,

          cnonce="b4972c8ee817300a7ff36ed1cbd59be", opaque="09e...",

          qop=auth,

          nc=00000001

        Security-Verify:

          ipsec-3gpp; ealg=null;

          alg=hmac-sha-1-96;

          spi-c=98765431; spi-s=87654321; port-c=(f)55063; port-s=(g)55062;

          q=0.9,

          ipsec-3gpp; ealg=null;

          alg=hmac-md5-96;

          spi-c=98765431; spi-s=87654321; port-c=(h)55063; port-s=(i)55062;

          q=0.7

        P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=31041000040000004

        Supported: sec-agree, path

        Proxy-Require: sec-agree

          Security-Client:

          ipsec-3gpp; ealg=aes-cbc;

          alg=hmac-sha-1-96;

          spi-c=41064354; spi-s=34933966; port-c=(j)50000; port-s=(k)50001; prot=esp;

          mod=trans, ipsec-3gpp;

          ealg=aes-cbc;

          alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966; port-c=(l)50000; port-s=(m)50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=des-ede3-cbc;

          alg=hmac-sha-1-96;

          spi-c=41064354; spi-s=34933966; port-c=(o)50000; port-s=(p)50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=des-ede3-cbc;

          alg=hmac-md5-96;

          spi-c=41064354; spi-s=34933966; port-c=(q)50000; port-s=(r)50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=null;

          alg=hmac-sha-1-96; spi-c=41064354; spi-s=34933966; port-c=(s)50000; port-s=(t)50001;

          prot=esp; mod=trans, ipsec-3gpp;

          ealg=null;

          alg=hmac-md5-96; spi-c=41064354; spi-s=34933966; port-c=(u)50000; port-s=(v)50001; prot=esp; mod=trans

        Require: sec-agree

        Content-Length: 0

 

 

    Transmission Control Protocol, (i)Src Port: 55063 , (ii)Dst Port: 50001 , Seq: 1302, Ack: 1, Len: 341

      INVITE sip:310410123456789@[3000::2:5547:21cb:7edf:9962]:50001;transport=tcp SIP/2.0

        Via: SIP/2.0/TCP [fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7]:55062; branch=z9hG4bK62b4a2938807

        Via: SIP/2.0/TCP scscf.anyims.test.3gpp.com; branch=z9hG4bK74eddae782b9

        Max-Forwards: 69

        To: <tel:+14251234567>

        From: <sip:+18472733800@one.att.net;user=phone>; tag=ATL2604_06f4d629ece8

        Call-ID: 551fe04688e4

        CSeq: 1 INVITE

        Via: SIP/2.0/TCP caller.3gpp.org:6543;branch=z9hG4bK87ee715641bd

        Record-Route: <sip:scscf.anyims.test.3gpp.com;lr>

        Record-Route: <sip:[fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7]:55062;lr>

        Supported: 100rel,precondition

        Allow: INVITE,ACK,CANCEL,BYE,UPDATE,PRACK,MESSAGE,REFER,NOTIFY

        P-Asserted-Identity: <sip:+18472733800@one.att.net;user=phone>

        P-Called-Party-ID: <tel:+14251234567>

        Contact: <sip:+18472733800@[3000:0:0:2::1]:5160>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video

        P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

        Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video

        Accept: application/sdp, application/3gpp-ims+xml

        Content-Length: 486

        Content-Type: application/sdp