• Type your task here, using "@" to assign to a user and "//" to select a due date

 

User Story

The customer develops his own softphone, that is planned to be advertised in Apple AppStore.

One of the new requirements for applications in Apple AppStore is supporting IPv6 DNS64/NAT64 networks.

In case of IPv6, it works with PortaSIP through NAT64, that performs proxying between IPv6 and IPv4 networks.Thus it is needed to adjust PortaSIP logic to allow processing of SIP requests / responses with IPv6 in headers as now b2bua cannot process them.

Without this modifications, the customer's application won't be authorized to be posted in AppStore.

Use Cases

Use case #1A: Call between 2 UAs with IPv6 via custom proxy

Roles: caller, callee, NAT64, PortaSIP, custom proxy (Customer's proxy with push-service)

Preconditions:

We have two accounts 111222 & 222333. They are configured on UAs with IPv6 addresses. These UAs are configured to send requests to custom proxy via NAT64.

Custom proxy routes calls between PortaSIP and UAs/NAT64 & processes RTP. 

PortaSIP uses IPv4.

Use scenario:

  • 111222 calls 222333

  • Call goes through NAT64 & custom proxy to PortaSIP

  • PortaSIP processes it and routes call to custom proxy

  • Custom proxy routes call to 222333 via NAT64
  • 222333 confirms the call & they start communication
  • media streams between IPv6 UAs are sent either directly or via third party media proxy.

Network chain:

UA (111222) -> NAT64 -> custom proxy -> PortaSIP -> custom proxy -> NAT64 -> UA (222333)

Use case #1B: Call between 2 UAs with IPv6

Roles: caller, callee, NAT64, PortaSIP

Preconditions:

We have two accounts 111222 & 222333. They are configured on UAs with IPv6 addresses. These UAs are configured to send requests to PortaSIP via NAT64.

PortaSIP uses IPv4.

Use scenario:

  • 111222 calls 222333

  • Call goes through NAT64 to PortaSIP

  • PortaSIP routes call to 222333 via NAT64

  • 222333 confirms the call & they start communication
  • media streams between IPv6 UAs are sent either directly or via PortaSIP media proxy.

Network chain:

UA (111222) -> NAT64 -> PortaSIP -> NAT64 -> UA (222333)

Use case #2A: Call from UA with IPv6 to UA/vendor with IPv4 via custom proxy

Roles: caller, callee/vendor, NAT64, PortaSIP, custom proxy (Customer's proxy with push-service)

Preconditions: 

We have two accounts 111222 & 222333. 

Caller's UA (111222) has IPv6 address. It is configured to send requests to custom proxy via NAT64. 

Callee's UA (222333) has IPv4 address.

333444 is a number outside the system.

Custom proxy routes calls between PortaSIP and UAs/NAT64 & processes RTP. 

PortaSIP uses IPv4.

Use scenario 2A.1: Call from UA with IPv6 to UA with IPv4

  • 111222 calls 222333

  • Call goes through NAT64 & custom proxy to PortaSIP

  • PortaSIP processes it and routes call to custom proxy

  • Custom proxy routes call to 222333
  • 222333 confirms the call & they start communication
  • media streams between UAs are sent either directly or via third party media proxy.

Network chain:

UA (111222) -> NAT64 -> custom proxy -> PortaSIP -> custom proxy -> UA (222333)

Use scenario 2A.2: Call from UA with IPv6 to vendor with IPv4

  • 111222 calls 333444

  • Call goes through NAT64 & custom proxy to PortaSIP

  • PortaSIP processes it and routes call to vendor

  • 333444 confirms the call & they start communication
  • media streams between parties are sent either directly or via third party media proxy.

Network chain:

UA (111222) -> NAT64 -> custom proxy -> PortaSIP -> vendor (333444)

Use case #2B: Call from UA with IPv6 to UA/vendor with IPv4

Roles: caller, callee/vendor, NAT64, PortaSIP

Preconditions: 

We have two accounts 111222 & 222333. 

Caller's UA (111222) has IPv6 address. It is configured to send requests to PortaSIP via NAT64. 

Callee's UA (222333) has IPv4 address.

333444 is a number outside the system.

PortaSIP uses IPv4.

Use scenario 2B.1: Call from UA with IPv6 to UA with IPv4

  • 111222 calls 222333

  • Call goes through NAT64 to PortaSIP

  • PortaSIP routes call to 222333

  • 222333 confirms the call & they start communication
  • media streams between UAs are sent either directly or via PortaSIP media proxy.

Network chain:

UA (111222) -> NAT64 -> PortaSIP -> UA (222333)

Use scenario 2B.2: Call from UA with IPv6 to vendor with IPv4

  • 111222 calls 333444

  • Call goes through NAT64 to PortaSIP

  • PortaSIP processes it and routes call to vendor

  • 333444 confirms the call & they start communication
  • media streams between parties are sent either directly or via PortaSIP media proxy.

Network chain:

UA (111222) -> NAT64 -> PortaSIP -> vendor (333444)

Use case #3A: Call from UA/vendor with IPv4 to UA with IPv6 via custom proxy

Roles: caller/vendor, callee, NAT64, PortaSIP, custom proxy (Customer's proxy with push-service)

Preconditions: 

We have two accounts 111222 & 222333.

Caller's UA (111222) has IPv4 address. 

Callee's UA (222333) has IPv6 address. It is configured to send requests to custom proxy via NAT64.

333444 is a number outside the system.

Custom proxy routes calls between PortaSIP and UAs/NAT64 & processes RTP.

PortaSIP uses IPv4.

Use scenario 3A.1: Call from UA with IPv4 to UA with IPv6

  • 111222 calls 222333

  • Call goes through custom proxy to PortaSIP

  • PortaSIP processes it and routes call to custom proxy

  • Custom proxy routes call to callee via NAT64
  • 222333 confirms the call & they start communication
  • media streams between UAs are sent either directly or via third party media proxy.

Network chain:

UA (111222) -> custom proxy -> PortaSIP -> custom proxy -> NAT64  -> UA (222333)

Use scenario 3A.2: Call from vendor with IPv4 to UA with IPv6

  • Vendor routes call from 333444 to 222333 to PortaSIP

  • PortaSIP processes it and routes call to custom proxy

  • Custom proxy routes call to callee via NAT64
  • 222333 confirms the call & they start communication
  • media streams between parties are sent either directly or via third party media proxy.

Network chain:

vendor (333444) -> PortaSIP -> custom proxy -> NAT64 -> UA (222333)

Use case #3B: Call from UA/vendor with IPv4 to UA with IPv6

Roles: caller/vendor, callee, NAT64, PortaSIP

Preconditions: 

We have two accounts 111222 & 222333.

Caller's UA (111222) has IPv4 address. 

Callee's UA (222333) has IPv6 address. It is configured to send requests to PortaSIP via NAT64.

333444 is a number outside the system.

PortaSIP uses IPv4.

Use scenario 3B.1: Call from UA with IPv4 to UA with IPv6

  • 111222 calls 222333

  • Call goes to PortaSIP

  • PortaSIP processes it and routes call to callee via NAT64

  • 222333 confirms the call & they start communication
  • media streams between UAs are sent either directly or via PortaSIP media proxy.

Network chain:

UA (111222) -> PortaSIP -> NAT64  -> UA (222333)

Use scenario 3B.2: Call from vendor with IPv4 to UA with IPv6

  • Vendor routes call from 333444 to 222333 to PortaSIP

  • PortaSIP processes it and routes call to callee via NAT64

  • 222333 confirms the call & they start communication
  • media streams between parties are sent either directly or via PortaSIP media proxy.

Network chain:

vendor (333444) -> PortaSIP -> NAT64 -> UA (222333)

Use case #4A: Support IPv6 for voice rejects via custom proxy

Roles: caller, NAT64, PortaSIP, custom proxy (Customer's proxy with push-service)

Preconditions:

We have two accounts 111222 & 222333.

111222 has insufficient funds. It is configured on UA with IPv6 address. This UA is configured to send requests to custom proxy via NAT64.

Custom proxy routes calls between PortaSIP and UAs/NAT64. 

Use scenario:

  • 111222 calls 222333

  • Call goes through NAT64 & custom proxy to PortaSIP

  • PortaSIP rejects call due to insufficient balance & plays the prompt about insufficient funds

  • media streams between parties are sent via third party media proxy.
  • Callee (111222) hears this prompt

Network chain:

UA (111222) -> NAT64 -> custom proxy -> PortaSIP

Use case #4B: Support IPv6 for voice rejects

Roles: caller, NAT64, PortaSIP

Preconditions:

We have two accounts 111222 & 222333.

111222 has insufficient funds. It is configured on UA with IPv6 address. This UA is configured to send requests to PortaSIP via NAT64.

Use scenario:

  • 111222 calls 222333

  • Call goes through NAT64 to PortaSIP

  • PortaSIP rejects call due to insufficient balance & plays the prompt about insufficient funds

  • media streams between parties are sent via PortaSIP media proxy.
  • Callee (111222) hears this prompt

Network chain:

UA (111222) -> NAT64 -> PortaSIP

Use case #5A: Call from UA with IPv6 to IVR via custom proxy

Roles: caller, NAT64, PortaSIP, custom proxy (Customer's proxy with push-service)

Preconditions:

We have account 111222. It is configured on UA with IPv6 address. This UA is configured to send requests to custom proxy via NAT64.

Custom proxy routes calls between PortaSIP and UAs/NAT64. 

Use scenario:

Network chain:

UA (111222) -> NAT64 -> custom proxy -> PortaSIP

Use case #5B: Call from UA with IPv6 to IVR

Roles: caller, NAT64, PortaSIP

Preconditions:

We have account 111222. It is configured on UA with IPv6 address. This UA is configured to send requests to PortaSIP via NAT64.

Use scenario:

Network chain:

UA (111222) -> NAT64 -> PortaSIP

Other requirements / constraints

  • We distinguish between A and B cases - with and without push/media custom proxy respectively. While B cases are more general, A cases are required for the particular deployment.
  • Call recording & legal intercept aren't used by particular customer [A cases], but generally these features are to be supported as well [B cases].
  • [A cases] We forward all calls to local accounts to their custom proxy server (static registration). It uses data about locations from our DB to route calls after this. Such a configuration has been done as this proxy is needed for PUSH-service.
  • [A cases] Custom proxy server is handling media proxying by one of its components - we call it "third party media proxy"
  • [A cases] Recommendations for testing from Apple can be found here ("Test for IPv6 DNS64/NAT64 Compatibility Regularly" section).
  • [A cases] Example of the INVITE from the call that customer tried on his system:
2016-06-23T09:33:54.490647Z|portaproxy[27907]|N4svrwP8FT|IS|1427| RECEIVED message from UDP:192.210.11.250:5228 at UDP:154.48.203.226:5060:
	INVITE sip:79111702557@argon.yollacalls.com;ver=3 SIP/2.0
	Via: SIP/2.0/UDP 192.210.11.250:5228;rport=5228;branch=z9hG4bK.eN64X92cyjQ1c097gXBc1HcQXa
	Via: SIP/2.0/TLS [2001:2::aab1:5c4e:67ed:c4d5:4888]:58067;branch=z9hG4bK.n59-N0y8-;rport=45110;received=154.48.203.254
	Max-Forwards: 69
	Record-Route: <sip:192.210.11.250:5228;lr>
	Record-Route: <sips:192.210.11.250:5223;lr>
	Contact: <sip:l79111364580@154.48.203.254:45110;transport=tls>;+sip.instance="<urn:uuid:33E7867F-F215-4299-A53F-259E72064772>"
	To: "+79111702557" <sip:79111702557@argon.yollacalls.com;ver=3>
	From: "+79111364580" <sip:l79111364580@argon.yollacalls.com>;tag=iQ1kKcA8v
	Call-ID: N4svrwP8FT
	CSeq: 20 INVITE
	Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
	Content-Type: application/sdp
	Supported: replaces, outbound, path
	User-Agent: Yolla/3.9.1-1423-gaf2ecd8 (belle-sip/1.4.2)
	Content-Length: 428
	
	v=0
	o=l79111364580 238 1151 IN IP6 2001:2::aab1:5c4e:67ed:c4d5:4888
	s=Talk
	c=IN IP6 2001:2::aab1:5c4e:67ed:c4d5:4888
	t=0 0
	a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
	m=audio 36768 RTP/AVP 96 97 101 98
	a=rtpmap:96 opus/48000/2
	a=fmtp:96 useinbandfec=1
	a=rtpmap:97 iLBC/8000
	a=fmtp:97 mode=30
	a=rtpmap:101 telephone-event/48000
	a=rtpmap:98 telephone-event/8000
	a=rtcp-fb:* trr-int 5000