Discussion:
[pjsip] NAT64 ios issue
Ashok Narvaneni
2017-03-31 14:14:23 UTC
Permalink
Hi,

We are trying to connect to IPV4 server from our pjsip ios app with NAT64.
We can able to register with the server successfully But when we make calls
their is no audio and call disconnects.
Below is the error.

*19:39:43.256 pjsua_media.c .....Call 1: updating media..*

*19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp() failed
for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*

*19:39:43.257 pjsua_media.c ......Error updating media call01:0:
Unsupported address family (PJ_EAFNOTSUP)*

*19:39:43.257 pjsua_media.c ......pjmedia_vid_stream_info_from_sdp()
failed for call_id 1 media 1: Unsupported address family (PJ_EAFNOTSUP)*

*19:39:43.257 pjsua_media.c ......Error updating media call01:1:
Unsupported address family (PJ_EAFNOTSUP)*

*19:39:43.257 pjsua_call.c .....Unable to create media session: No
active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
[status=220048]*

*19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*

What could be wrong? Can someone please help me on this.

Thanks,

Ashok Narvaneni.
Colin Morelli
2017-03-31 14:38:23 UTC
Permalink
Ashok,

What's almost certainly happening here is that the SDP returned from your
server contains only IPv4 media addresses. When PJSIP goes to compare the
SDP to local capabilities, it finds only IPv4 addresses for the remote
endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
there's no way it can communicate with the remote server and fails.

I have been able to fix this with two steps:

1) Enable ICE negotiation on both your media server and PJSIP client. ICE
is helpful here because it allows the two endpoints to communicate multiple
candidate media addresses. This step *may* be optional, although I've never
really tested without this.
2) Write a PJSIP module that intercepts incoming/outgoing SDPs to work
around the NAT64 issue. There's an example of one of these on github
<https://github.com/johanlantz/pj-nat64>, and I've written my own for my
app (unfortunately can't share at this time). The general steps that need
to be followed here are:

- Intercept on_tx and on_rx PJSIP events
- When sending an outgoing SDP, if signaling is connected over IPv6, then
add an IPv4 address to the ICE candidates in the SDP (this step is
optional, and depends on whether or not your server will explicitly reject
an SDP that only contains IPv6 addresses)
- When receiving an incoming SDP, if signaling is connected over IPv6,
then iterate the ICE candidates in the SDP, find all IPv4 addresses,
synthesize IPv6 addresses for them (by passing the IPv4 addresses to
pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
a NAT64 network), and add the synthesized IPv6 addresses to the ICE
candidates list

As long as this module is registered with a higher priority than the PJSIP
transports module, the SDP will be rewritten before pjmedia actually parses
the SDP. By the time it gets to the media stack, it will see your
synthesized IPv6 addresses, which it can support, and should be able to
establish a media connection.

Couple of tips here: don't underestimate the nuances of this issue. It's
not necessarily a *hard *problem, but there are a lot of cases to consider.
Once you solve the first issue, you then have the issue of what happens
when the user changes networks during a call (i.e. their phone switches
wifi networks, or off of wifi entirely). Additionally, if you're working on
Android, you probably have this issue on Android as well, but Google as far
as I know does not test apps on a NAT64 network like Apple does.

Apologies I can't be more specific at this time but I hope this points you
in the right direction. I think it'd be great for PJSIP to include this in
the core. NAT64 networks are likely to become more prevalent, and it would
be considerably less work to simply add to the core than it would be to
maintain a separate module.

Best,
Colin

On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <***@gmail.com
> wrote:

> Hi,
>
> We are trying to connect to IPV4 server from our pjsip ios app with NAT64.
> We can able to register with the server successfully But when we make
> calls their is no audio and call disconnects.
> Below is the error.
>
> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>
> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp() failed
> for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>
> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
> Unsupported address family (PJ_EAFNOTSUP)*
>
> *19:39:43.257 pjsua_media.c ......pjmedia_vid_stream_info_from_sdp()
> failed for call_id 1 media 1: Unsupported address family (PJ_EAFNOTSUP)*
>
> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
> Unsupported address family (PJ_EAFNOTSUP)*
>
> *19:39:43.257 pjsua_call.c .....Unable to create media session: No
> active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
> [status=220048]*
>
> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>
> What could be wrong? Can someone please help me on this.
>
> Thanks,
>
> Ashok Narvaneni.
>
>
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
Ashok Narvaneni
2017-03-31 14:44:01 UTC
Permalink
Hi Colin,

Thank you very much for detailed answer, I will try that patch and post my
findings.

Thanks,
Ashok.

On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <***@gmail.com>
wrote:

> Ashok,
>
> What's almost certainly happening here is that the SDP returned from your
> server contains only IPv4 media addresses. When PJSIP goes to compare the
> SDP to local capabilities, it finds only IPv4 addresses for the remote
> endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
> there's no way it can communicate with the remote server and fails.
>
> I have been able to fix this with two steps:
>
> 1) Enable ICE negotiation on both your media server and PJSIP client. ICE
> is helpful here because it allows the two endpoints to communicate multiple
> candidate media addresses. This step *may* be optional, although I've never
> really tested without this.
> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to work
> around the NAT64 issue. There's an example of one of these on github
> <https://github.com/johanlantz/pj-nat64>, and I've written my own for my
> app (unfortunately can't share at this time). The general steps that need
> to be followed here are:
>
> - Intercept on_tx and on_rx PJSIP events
> - When sending an outgoing SDP, if signaling is connected over IPv6, then
> add an IPv4 address to the ICE candidates in the SDP (this step is
> optional, and depends on whether or not your server will explicitly reject
> an SDP that only contains IPv6 addresses)
> - When receiving an incoming SDP, if signaling is connected over IPv6,
> then iterate the ICE candidates in the SDP, find all IPv4 addresses,
> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
> candidates list
>
> As long as this module is registered with a higher priority than the PJSIP
> transports module, the SDP will be rewritten before pjmedia actually parses
> the SDP. By the time it gets to the media stack, it will see your
> synthesized IPv6 addresses, which it can support, and should be able to
> establish a media connection.
>
> Couple of tips here: don't underestimate the nuances of this issue. It's
> not necessarily a *hard *problem, but there are a lot of cases to
> consider. Once you solve the first issue, you then have the issue of what
> happens when the user changes networks during a call (i.e. their phone
> switches wifi networks, or off of wifi entirely). Additionally, if you're
> working on Android, you probably have this issue on Android as well, but
> Google as far as I know does not test apps on a NAT64 network like Apple
> does.
>
> Apologies I can't be more specific at this time but I hope this points you
> in the right direction. I think it'd be great for PJSIP to include this in
> the core. NAT64 networks are likely to become more prevalent, and it would
> be considerably less work to simply add to the core than it would be to
> maintain a separate module.
>
> Best,
> Colin
>
> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
> ***@gmail.com> wrote:
>
>> Hi,
>>
>> We are trying to connect to IPV4 server from our pjsip ios app with NAT64.
>> We can able to register with the server successfully But when we make
>> calls their is no audio and call disconnects.
>> Below is the error.
>>
>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>
>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp() failed
>> for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>
>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>> Unsupported address family (PJ_EAFNOTSUP)*
>>
>> *19:39:43.257 pjsua_media.c ......pjmedia_vid_stream_info_from_sdp()
>> failed for call_id 1 media 1: Unsupported address family (PJ_EAFNOTSUP)*
>>
>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>> Unsupported address family (PJ_EAFNOTSUP)*
>>
>> *19:39:43.257 pjsua_call.c .....Unable to create media session: No
>> active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>> [status=220048]*
>>
>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>
>> What could be wrong? Can someone please help me on this.
>>
>> Thanks,
>>
>> Ashok Narvaneni.
>>
>>
>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> ***@lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
Ashok Narvaneni
2017-04-04 14:23:43 UTC
Permalink
Hi Colin,

We integrated the module as you suggested and it is working fine.
However it breaks when we connect the device with an IPV4 network. We
understand that pjsip does't support dual stack mode. So what is the best
way to do make the App work with both IPV6 and IPV4 networks.
Please suggest...

Thanks,
Ashok Narvaneni.


On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <***@gmail.com>
wrote:

> Hi Colin,
>
> Thank you very much for detailed answer, I will try that patch and post my
> findings.
>
> Thanks,
> Ashok.
>
> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <***@gmail.com>
> wrote:
>
>> Ashok,
>>
>> What's almost certainly happening here is that the SDP returned from your
>> server contains only IPv4 media addresses. When PJSIP goes to compare the
>> SDP to local capabilities, it finds only IPv4 addresses for the remote
>> endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
>> there's no way it can communicate with the remote server and fails.
>>
>> I have been able to fix this with two steps:
>>
>> 1) Enable ICE negotiation on both your media server and PJSIP client.
>> ICE is helpful here because it allows the two endpoints to communicate
>> multiple candidate media addresses. This step *may* be optional, although
>> I've never really tested without this.
>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to work
>> around the NAT64 issue. There's an example of one of these on github
>> <https://github.com/johanlantz/pj-nat64>, and I've written my own for my
>> app (unfortunately can't share at this time). The general steps that need
>> to be followed here are:
>>
>> - Intercept on_tx and on_rx PJSIP events
>> - When sending an outgoing SDP, if signaling is connected over IPv6,
>> then add an IPv4 address to the ICE candidates in the SDP (this step is
>> optional, and depends on whether or not your server will explicitly reject
>> an SDP that only contains IPv6 addresses)
>> - When receiving an incoming SDP, if signaling is connected over IPv6,
>> then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>> candidates list
>>
>> As long as this module is registered with a higher priority than the
>> PJSIP transports module, the SDP will be rewritten before pjmedia actually
>> parses the SDP. By the time it gets to the media stack, it will see your
>> synthesized IPv6 addresses, which it can support, and should be able to
>> establish a media connection.
>>
>> Couple of tips here: don't underestimate the nuances of this issue. It's
>> not necessarily a *hard *problem, but there are a lot of cases to
>> consider. Once you solve the first issue, you then have the issue of what
>> happens when the user changes networks during a call (i.e. their phone
>> switches wifi networks, or off of wifi entirely). Additionally, if you're
>> working on Android, you probably have this issue on Android as well, but
>> Google as far as I know does not test apps on a NAT64 network like Apple
>> does.
>>
>> Apologies I can't be more specific at this time but I hope this points
>> you in the right direction. I think it'd be great for PJSIP to include this
>> in the core. NAT64 networks are likely to become more prevalent, and it
>> would be considerably less work to simply add to the core than it would be
>> to maintain a separate module.
>>
>> Best,
>> Colin
>>
>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>> ***@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> We are trying to connect to IPV4 server from our pjsip ios app with
>>> NAT64.
>>> We can able to register with the server successfully But when we make
>>> calls their is no audio and call disconnects.
>>> Below is the error.
>>>
>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>
>>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp()
>>> failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>>
>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>
>>> *19:39:43.257 pjsua_media.c ......pjmedia_vid_stream_info_from_sdp()
>>> failed for call_id 1 media 1: Unsupported address family (PJ_EAFNOTSUP)*
>>>
>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>
>>> *19:39:43.257 pjsua_call.c .....Unable to create media session: No
>>> active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>> [status=220048]*
>>>
>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>
>>> What could be wrong? Can someone please help me on this.
>>>
>>> Thanks,
>>>
>>> Ashok Narvaneni.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> ***@lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
Colin Morelli
2017-04-04 14:29:34 UTC
Permalink
Ahsok,

This is one of the reasons I had written my own module (well, that and
supporting ICE). The module I linked does not perform any checks about the
current connection to the SIP server. Among other things, one of the
additional things my modules does is only operate when connected to the
signaling server via IPv6. This can be accomplished by a simple check in
the on_rx and on_tx methods, before touching the SDP:

(tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
== PJSIP_TRANSPORT_IPV6

With that check at the beginning of the module methods, it should simply
ignore anything that happens on an IPv4 transport and leave the SDP
in-tact.

As for PJSIP supporting dual stack mode - there's really no sense in trying
to do this when ICE is available. PJSIP's ICE implementation can and does
support dual stack. If you can enable ICE on your server side as well, that
should work for your use case.

Best,
Colin

On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <***@gmail.com>
wrote:

> Hi Colin,
>
> We integrated the module as you suggested and it is working fine.
> However it breaks when we connect the device with an IPV4 network. We
> understand that pjsip does't support dual stack mode. So what is the best
> way to do make the App work with both IPV6 and IPV4 networks.
> Please suggest...
>
> Thanks,
> Ashok Narvaneni.
>
>
> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
> ***@gmail.com> wrote:
>
>> Hi Colin,
>>
>> Thank you very much for detailed answer, I will try that patch and post
>> my findings.
>>
>> Thanks,
>> Ashok.
>>
>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <***@gmail.com>
>> wrote:
>>
>>> Ashok,
>>>
>>> What's almost certainly happening here is that the SDP returned from
>>> your server contains only IPv4 media addresses. When PJSIP goes to compare
>>> the SDP to local capabilities, it finds only IPv4 addresses for the remote
>>> endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
>>> there's no way it can communicate with the remote server and fails.
>>>
>>> I have been able to fix this with two steps:
>>>
>>> 1) Enable ICE negotiation on both your media server and PJSIP client.
>>> ICE is helpful here because it allows the two endpoints to communicate
>>> multiple candidate media addresses. This step *may* be optional, although
>>> I've never really tested without this.
>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to work
>>> around the NAT64 issue. There's an example of one of these on github
>>> <https://github.com/johanlantz/pj-nat64>, and I've written my own for
>>> my app (unfortunately can't share at this time). The general steps that
>>> need to be followed here are:
>>>
>>> - Intercept on_tx and on_rx PJSIP events
>>> - When sending an outgoing SDP, if signaling is connected over IPv6,
>>> then add an IPv4 address to the ICE candidates in the SDP (this step is
>>> optional, and depends on whether or not your server will explicitly reject
>>> an SDP that only contains IPv6 addresses)
>>> - When receiving an incoming SDP, if signaling is connected over IPv6,
>>> then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>> candidates list
>>>
>>> As long as this module is registered with a higher priority than the
>>> PJSIP transports module, the SDP will be rewritten before pjmedia actually
>>> parses the SDP. By the time it gets to the media stack, it will see your
>>> synthesized IPv6 addresses, which it can support, and should be able to
>>> establish a media connection.
>>>
>>> Couple of tips here: don't underestimate the nuances of this issue. It's
>>> not necessarily a *hard *problem, but there are a lot of cases to
>>> consider. Once you solve the first issue, you then have the issue of what
>>> happens when the user changes networks during a call (i.e. their phone
>>> switches wifi networks, or off of wifi entirely). Additionally, if you're
>>> working on Android, you probably have this issue on Android as well, but
>>> Google as far as I know does not test apps on a NAT64 network like Apple
>>> does.
>>>
>>> Apologies I can't be more specific at this time but I hope this points
>>> you in the right direction. I think it'd be great for PJSIP to include this
>>> in the core. NAT64 networks are likely to become more prevalent, and it
>>> would be considerably less work to simply add to the core than it would be
>>> to maintain a separate module.
>>>
>>> Best,
>>> Colin
>>>
>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>> ***@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> We are trying to connect to IPV4 server from our pjsip ios app with
>>>> NAT64.
>>>> We can able to register with the server successfully But when we make
>>>> calls their is no audio and call disconnects.
>>>> Below is the error.
>>>>
>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>
>>>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp()
>>>> failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>
>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>
>>>> *19:39:43.257 pjsua_media.c ......pjmedia_vid_stream_info_from_sdp()
>>>> failed for call_id 1 media 1: Unsupported address family (PJ_EAFNOTSUP)*
>>>>
>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>
>>>> *19:39:43.257 pjsua_call.c .....Unable to create media session: No
>>>> active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>> [status=220048]*
>>>>
>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>
>>>> What could be wrong? Can someone please help me on this.
>>>>
>>>> Thanks,
>>>>
>>>> Ashok Narvaneni.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> ***@lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
Ashok Narvaneni
2017-04-04 14:36:41 UTC
Permalink
Hi Colin,

Thanks again for your kind reply.
We will make the changes and post our findings.
Unfortunately this server is provided by our client which does't have ICE
support.

Thanks,
Ashok Narvaneni.

On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com>
wrote:

> Ahsok,
>
> This is one of the reasons I had written my own module (well, that and
> supporting ICE). The module I linked does not perform any checks about the
> current connection to the SIP server. Among other things, one of the
> additional things my modules does is only operate when connected to the
> signaling server via IPv6. This can be accomplished by a simple check in
> the on_rx and on_tx methods, before touching the SDP:
>
> (tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
> == PJSIP_TRANSPORT_IPV6
>
> With that check at the beginning of the module methods, it should simply
> ignore anything that happens on an IPv4 transport and leave the SDP
> in-tact.
>
> As for PJSIP supporting dual stack mode - there's really no sense in
> trying to do this when ICE is available. PJSIP's ICE implementation can and
> does support dual stack. If you can enable ICE on your server side as well,
> that should work for your use case.
>
> Best,
> Colin
>
> On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <
> ***@gmail.com> wrote:
>
>> Hi Colin,
>>
>> We integrated the module as you suggested and it is working fine.
>> However it breaks when we connect the device with an IPV4 network. We
>> understand that pjsip does't support dual stack mode. So what is the best
>> way to do make the App work with both IPV6 and IPV4 networks.
>> Please suggest...
>>
>> Thanks,
>> Ashok Narvaneni.
>>
>>
>> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
>> ***@gmail.com> wrote:
>>
>>> Hi Colin,
>>>
>>> Thank you very much for detailed answer, I will try that patch and post
>>> my findings.
>>>
>>> Thanks,
>>> Ashok.
>>>
>>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <***@gmail.com>
>>> wrote:
>>>
>>>> Ashok,
>>>>
>>>> What's almost certainly happening here is that the SDP returned from
>>>> your server contains only IPv4 media addresses. When PJSIP goes to compare
>>>> the SDP to local capabilities, it finds only IPv4 addresses for the remote
>>>> endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
>>>> there's no way it can communicate with the remote server and fails.
>>>>
>>>> I have been able to fix this with two steps:
>>>>
>>>> 1) Enable ICE negotiation on both your media server and PJSIP client.
>>>> ICE is helpful here because it allows the two endpoints to communicate
>>>> multiple candidate media addresses. This step *may* be optional, although
>>>> I've never really tested without this.
>>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to work
>>>> around the NAT64 issue. There's an example of one of these on github
>>>> <https://github.com/johanlantz/pj-nat64>, and I've written my own for
>>>> my app (unfortunately can't share at this time). The general steps that
>>>> need to be followed here are:
>>>>
>>>> - Intercept on_tx and on_rx PJSIP events
>>>> - When sending an outgoing SDP, if signaling is connected over IPv6,
>>>> then add an IPv4 address to the ICE candidates in the SDP (this step is
>>>> optional, and depends on whether or not your server will explicitly reject
>>>> an SDP that only contains IPv6 addresses)
>>>> - When receiving an incoming SDP, if signaling is connected over IPv6,
>>>> then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>>> candidates list
>>>>
>>>> As long as this module is registered with a higher priority than the
>>>> PJSIP transports module, the SDP will be rewritten before pjmedia actually
>>>> parses the SDP. By the time it gets to the media stack, it will see your
>>>> synthesized IPv6 addresses, which it can support, and should be able to
>>>> establish a media connection.
>>>>
>>>> Couple of tips here: don't underestimate the nuances of this issue.
>>>> It's not necessarily a *hard *problem, but there are a lot of cases to
>>>> consider. Once you solve the first issue, you then have the issue of what
>>>> happens when the user changes networks during a call (i.e. their phone
>>>> switches wifi networks, or off of wifi entirely). Additionally, if you're
>>>> working on Android, you probably have this issue on Android as well, but
>>>> Google as far as I know does not test apps on a NAT64 network like Apple
>>>> does.
>>>>
>>>> Apologies I can't be more specific at this time but I hope this points
>>>> you in the right direction. I think it'd be great for PJSIP to include this
>>>> in the core. NAT64 networks are likely to become more prevalent, and it
>>>> would be considerably less work to simply add to the core than it would be
>>>> to maintain a separate module.
>>>>
>>>> Best,
>>>> Colin
>>>>
>>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>>> ***@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> We are trying to connect to IPV4 server from our pjsip ios app with
>>>>> NAT64.
>>>>> We can able to register with the server successfully But when we make
>>>>> calls their is no audio and call disconnects.
>>>>> Below is the error.
>>>>>
>>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>>
>>>>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp()
>>>>> failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>
>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>
>>>>> *19:39:43.257 pjsua_media.c ......pjmedia_vid_stream_info_from_sdp()
>>>>> failed for call_id 1 media 1: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>
>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>
>>>>> *19:39:43.257 pjsua_call.c .....Unable to create media session: No
>>>>> active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>>> [status=220048]*
>>>>>
>>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>>
>>>>> What could be wrong? Can someone please help me on this.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ashok Narvaneni.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Visit our blog: http://blog.pjsip.org
>>>>>
>>>>> pjsip mailing list
>>>>> ***@lists.pjsip.org
>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> ***@lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> ***@lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
JOHAN LANTZ
2017-04-04 14:45:29 UTC
Permalink
Hi Ashok

Glad the module is more or less doing the job for you. As you can see in the README.md file on GitHub under bullet 2, there is an example on how you can activate this only when connecting to a IPv6 network. Then IPv4 continues to work as it has always done. Just hook it into the on_registration callback from pjsip and I think you will be fine.

Johan

From: pjsip on behalf of Ashok Narvaneni
Reply-To: pjsip list
Date: Tuesday, 4 April 2017 at 16:36
To: pjsip list
Subject: Re: [pjsip] NAT64 ios issue

Hi Colin,

Thanks again for your kind reply.
We will make the changes and post our findings.
Unfortunately this server is provided by our client which does't have ICE support.

Thanks,
Ashok Narvaneni.

On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com<mailto:***@gmail.com>> wrote:
Ahsok,

This is one of the reasons I had written my own module (well, that and supporting ICE). The module I linked does not perform any checks about the current connection to the SIP server. Among other things, one of the additional things my modules does is only operate when connected to the signaling server via IPv6. This can be accomplished by a simple check in the on_rx and on_tx methods, before touching the SDP:

(tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6) == PJSIP_TRANSPORT_IPV6

With that check at the beginning of the module methods, it should simply ignore anything that happens on an IPv4 transport and leave the SDP in-tact.

As for PJSIP supporting dual stack mode - there's really no sense in trying to do this when ICE is available. PJSIP's ICE implementation can and does support dual stack. If you can enable ICE on your server side as well, that should work for your use case.

Best,
Colin

On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi Colin,

We integrated the module as you suggested and it is working fine.
However it breaks when we connect the device with an IPV4 network. We understand that pjsip does't support dual stack mode. So what is the best way to do make the App work with both IPV6 and IPV4 networks.
Please suggest...

Thanks,
Ashok Narvaneni.


On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi Colin,

Thank you very much for detailed answer, I will try that patch and post my findings.

Thanks,
Ashok.

On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <***@gmail.com<mailto:***@gmail.com>> wrote:
Ashok,

What's almost certainly happening here is that the SDP returned from your server contains only IPv4 media addresses. When PJSIP goes to compare the SDP to local capabilities, it finds only IPv4 addresses for the remote endpoint, but can't find any local IPv4 interfaces. As a result, it thinks there's no way it can communicate with the remote server and fails.

I have been able to fix this with two steps:

1) Enable ICE negotiation on both your media server and PJSIP client. ICE is helpful here because it allows the two endpoints to communicate multiple candidate media addresses. This step *may* be optional, although I've never really tested without this.
2) Write a PJSIP module that intercepts incoming/outgoing SDPs to work around the NAT64 issue. There's an example of one of these on github<https://github.com/johanlantz/pj-nat64>, and I've written my own for my app (unfortunately can't share at this time). The general steps that need to be followed here are:

- Intercept on_tx and on_rx PJSIP events
- When sending an outgoing SDP, if signaling is connected over IPv6, then add an IPv4 address to the ICE candidates in the SDP (this step is optional, and depends on whether or not your server will explicitly reject an SDP that only contains IPv6 addresses)
- When receiving an incoming SDP, if signaling is connected over IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses, synthesize IPv6 addresses for them (by passing the IPv4 addresses to pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to a NAT64 network), and add the synthesized IPv6 addresses to the ICE candidates list

As long as this module is registered with a higher priority than the PJSIP transports module, the SDP will be rewritten before pjmedia actually parses the SDP. By the time it gets to the media stack, it will see your synthesized IPv6 addresses, which it can support, and should be able to establish a media connection.

Couple of tips here: don't underestimate the nuances of this issue. It's not necessarily a hard problem, but there are a lot of cases to consider. Once you solve the first issue, you then have the issue of what happens when the user changes networks during a call (i.e. their phone switches wifi networks, or off of wifi entirely). Additionally, if you're working on Android, you probably have this issue on Android as well, but Google as far as I know does not test apps on a NAT64 network like Apple does.

Apologies I can't be more specific at this time but I hope this points you in the right direction. I think it'd be great for PJSIP to include this in the core. NAT64 networks are likely to become more prevalent, and it would be considerably less work to simply add to the core than it would be to maintain a separate module.

Best,
Colin

On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi,

We are trying to connect to IPV4 server from our pjsip ios app with NAT64.
We can able to register with the server successfully But when we make calls their is no audio and call disconnects.
Below is the error.

19:39:43.256 pjsua_media.c .....Call 1: updating media..

19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp() failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)

19:39:43.257 pjsua_media.c ......Error updating media call01:0: Unsupported address family (PJ_EAFNOTSUP)

19:39:43.257 pjsua_media.c ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1: Unsupported address family (PJ_EAFNOTSUP)

19:39:43.257 pjsua_media.c ......Error updating media call01:1: Unsupported address family (PJ_EAFNOTSUP)

19:39:43.257 pjsua_call.c .....Unable to create media session: No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA) [status=220048]

19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:

What could be wrong? Can someone please help me on this.

Thanks,

Ashok Narvaneni.




_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org



_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org




_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org



_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Ashok Narvaneni
2017-04-05 12:40:25 UTC
Permalink
Thank you very much Colin and Johan for your help.

We have made some good progress. Below is the current status.
IPV4 - Phone register successfully, both Incoming and outgoing calls are
working fine.
IPV6 - Phone register successfully, outgoing calls are working fine but
when some one dial the extension of the phone under IPV6, FreeSwitch server
doesn't send the INVITE to the phone .

Below is the register packet received on the server. Is there any other
change we need to make on the app or Is that a FreeSwitch issue. Contact
header have IPV6 address.

REGISTER sip:xxxxxx.xxx;transport=TCP SIP/2.0
Via: SIP/2.0/TCP
[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;rport;branch=z9hG4bKPjq-wL2PpL4k0klpjECGxQ7duSoDQPzA6-;alias
Max-Forwards: 70
From: <sip:***@xxxxxx.xxx>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
To: <sip:***@xxxxxx.xxx>
Call-ID: rQmIvhvfa8krjErV-bKQTnDcsfK79INU
CSeq: 57007 REGISTER
User-Agent: SIPUA-1.0 iOS-10.0.1/arm-iPhone8,1/iOS-SDK
Supported: outbound, path
Contact: <sip:103@
[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000fea119f6>"
Expires: 60
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length: 0

Thanks,
Ashok Narvaneni.

On Tue, Apr 4, 2017 at 8:15 PM, JOHAN LANTZ <***@telefonica.com>
wrote:

> Hi Ashok
>
> Glad the module is more or less doing the job for you. As you can see in
> the README.md file on GitHub under bullet 2, there is an example on how you
> can activate this only when connecting to a IPv6 network. Then IPv4
> continues to work as it has always done. Just hook it into the
> on_registration callback from pjsip and I think you will be fine.
>
> Johan
>
> From: pjsip on behalf of Ashok Narvaneni
> Reply-To: pjsip list
> Date: Tuesday, 4 April 2017 at 16:36
> To: pjsip list
> Subject: Re: [pjsip] NAT64 ios issue
>
> Hi Colin,
>
> Thanks again for your kind reply.
> We will make the changes and post our findings.
> Unfortunately this server is provided by our client which does't have ICE
> support.
>
> Thanks,
> Ashok Narvaneni.
>
> On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com>
> wrote:
>
>> Ahsok,
>>
>> This is one of the reasons I had written my own module (well, that and
>> supporting ICE). The module I linked does not perform any checks about the
>> current connection to the SIP server. Among other things, one of the
>> additional things my modules does is only operate when connected to the
>> signaling server via IPv6. This can be accomplished by a simple check in
>> the on_rx and on_tx methods, before touching the SDP:
>>
>> (tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
>> == PJSIP_TRANSPORT_IPV6
>>
>> With that check at the beginning of the module methods, it should simply
>> ignore anything that happens on an IPv4 transport and leave the SDP
>> in-tact.
>>
>> As for PJSIP supporting dual stack mode - there's really no sense in
>> trying to do this when ICE is available. PJSIP's ICE implementation can and
>> does support dual stack. If you can enable ICE on your server side as well,
>> that should work for your use case.
>>
>> Best,
>> Colin
>>
>> On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <
>> ***@gmail.com> wrote:
>>
>>> Hi Colin,
>>>
>>> We integrated the module as you suggested and it is working fine.
>>> However it breaks when we connect the device with an IPV4 network. We
>>> understand that pjsip does't support dual stack mode. So what is the best
>>> way to do make the App work with both IPV6 and IPV4 networks.
>>> Please suggest...
>>>
>>> Thanks,
>>> Ashok Narvaneni.
>>>
>>>
>>> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
>>> ***@gmail.com> wrote:
>>>
>>>> Hi Colin,
>>>>
>>>> Thank you very much for detailed answer, I will try that patch and post
>>>> my findings.
>>>>
>>>> Thanks,
>>>> Ashok.
>>>>
>>>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <***@gmail.com
>>>> > wrote:
>>>>
>>>>> Ashok,
>>>>>
>>>>> What's almost certainly happening here is that the SDP returned from
>>>>> your server contains only IPv4 media addresses. When PJSIP goes to compare
>>>>> the SDP to local capabilities, it finds only IPv4 addresses for the remote
>>>>> endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
>>>>> there's no way it can communicate with the remote server and fails.
>>>>>
>>>>> I have been able to fix this with two steps:
>>>>>
>>>>> 1) Enable ICE negotiation on both your media server and PJSIP client.
>>>>> ICE is helpful here because it allows the two endpoints to communicate
>>>>> multiple candidate media addresses. This step *may* be optional, although
>>>>> I've never really tested without this.
>>>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to
>>>>> work around the NAT64 issue. There's an example of one of these on
>>>>> github <https://github.com/johanlantz/pj-nat64>, and I've written my
>>>>> own for my app (unfortunately can't share at this time). The general steps
>>>>> that need to be followed here are:
>>>>>
>>>>> - Intercept on_tx and on_rx PJSIP events
>>>>> - When sending an outgoing SDP, if signaling is connected over IPv6,
>>>>> then add an IPv4 address to the ICE candidates in the SDP (this step is
>>>>> optional, and depends on whether or not your server will explicitly reject
>>>>> an SDP that only contains IPv6 addresses)
>>>>> - When receiving an incoming SDP, if signaling is connected over
>>>>> IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>>>> candidates list
>>>>>
>>>>> As long as this module is registered with a higher priority than the
>>>>> PJSIP transports module, the SDP will be rewritten before pjmedia actually
>>>>> parses the SDP. By the time it gets to the media stack, it will see your
>>>>> synthesized IPv6 addresses, which it can support, and should be able to
>>>>> establish a media connection.
>>>>>
>>>>> Couple of tips here: don't underestimate the nuances of this issue.
>>>>> It's not necessarily a *hard *problem, but there are a lot of cases
>>>>> to consider. Once you solve the first issue, you then have the issue of
>>>>> what happens when the user changes networks during a call (i.e. their phone
>>>>> switches wifi networks, or off of wifi entirely). Additionally, if you're
>>>>> working on Android, you probably have this issue on Android as well, but
>>>>> Google as far as I know does not test apps on a NAT64 network like Apple
>>>>> does.
>>>>>
>>>>> Apologies I can't be more specific at this time but I hope this points
>>>>> you in the right direction. I think it'd be great for PJSIP to include this
>>>>> in the core. NAT64 networks are likely to become more prevalent, and it
>>>>> would be considerably less work to simply add to the core than it would be
>>>>> to maintain a separate module.
>>>>>
>>>>> Best,
>>>>> Colin
>>>>>
>>>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>>>> ***@gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We are trying to connect to IPV4 server from our pjsip ios app with
>>>>>> NAT64.
>>>>>> We can able to register with the server successfully But when we make
>>>>>> calls their is no audio and call disconnects.
>>>>>> Below is the error.
>>>>>>
>>>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>>>
>>>>>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp()
>>>>>> failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>
>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>
>>>>>> *19:39:43.257 pjsua_media.c
>>>>>> ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1:
>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>
>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>
>>>>>> *19:39:43.257 pjsua_call.c .....Unable to create media session: No
>>>>>> active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>>>> [status=220048]*
>>>>>>
>>>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>>>
>>>>>> What could be wrong? Can someone please help me on this.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Ashok Narvaneni.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>
>>>>>> pjsip mailing list
>>>>>> ***@lists.pjsip.org
>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Visit our blog: http://blog.pjsip.org
>>>>>
>>>>> pjsip mailing list
>>>>> ***@lists.pjsip.org
>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> ***@lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
JOHAN LANTZ
2017-04-05 12:49:16 UTC
Permalink
For this problem I really do not know. I think our system does not pay that much attention to the Contact header but simply connects the registered device with the TCP/TLS socket used.

I doubt there is anything missing on the client side if you simply does not receive the INVITE. Are other packets reaching the device? MESSAGE, keep-alive, etc?

Johan

From: pjsip on behalf of Ashok Narvaneni
Reply-To: pjsip list
Date: Wednesday, 5 April 2017 at 14:40
To: pjsip list
Subject: Re: [pjsip] NAT64 ios issue

Thank you very much Colin and Johan for your help.

We have made some good progress. Below is the current status.
IPV4 - Phone register successfully, both Incoming and outgoing calls are working fine.
IPV6 - Phone register successfully, outgoing calls are working fine but when some one dial the extension of the phone under IPV6, FreeSwitch server doesn't send the INVITE to the phone .

Below is the register packet received on the server. Is there any other change we need to make on the app or Is that a FreeSwitch issue. Contact header have IPV6 address.

REGISTER sip:xxxxxx.xxx;transport=TCP SIP/2.0
Via: SIP/2.0/TCP [2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;rport;branch=z9hG4bKPjq-wL2PpL4k0klpjECGxQ7duSoDQPzA6-;alias
Max-Forwards: 70
From: <sip:***@xxxxxx.xxx<mailto:***@xxxxxx.xxx>>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
To: <sip:***@xxxxxx.xxx<mailto:***@xxxxxx.xxx>>
Call-ID: rQmIvhvfa8krjErV-bKQTnDcsfK79INU
CSeq: 57007 REGISTER
User-Agent: SIPUA-1.0 iOS-10.0.1/arm-iPhone8,1/iOS-SDK
Supported: outbound, path
Contact: <sip:103@[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000fea119f6>"
Expires: 60
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0

Thanks,
Ashok Narvaneni.

On Tue, Apr 4, 2017 at 8:15 PM, JOHAN LANTZ <***@telefonica.com<mailto:***@telefonica.com>> wrote:
Hi Ashok

Glad the module is more or less doing the job for you. As you can see in the README.md file on GitHub under bullet 2, there is an example on how you can activate this only when connecting to a IPv6 network. Then IPv4 continues to work as it has always done. Just hook it into the on_registration callback from pjsip and I think you will be fine.

Johan

From: pjsip on behalf of Ashok Narvaneni
Reply-To: pjsip list
Date: Tuesday, 4 April 2017 at 16:36
To: pjsip list
Subject: Re: [pjsip] NAT64 ios issue

Hi Colin,

Thanks again for your kind reply.
We will make the changes and post our findings.
Unfortunately this server is provided by our client which does't have ICE support.

Thanks,
Ashok Narvaneni.

On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com<mailto:***@gmail.com>> wrote:
Ahsok,

This is one of the reasons I had written my own module (well, that and supporting ICE). The module I linked does not perform any checks about the current connection to the SIP server. Among other things, one of the additional things my modules does is only operate when connected to the signaling server via IPv6. This can be accomplished by a simple check in the on_rx and on_tx methods, before touching the SDP:

(tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6) == PJSIP_TRANSPORT_IPV6

With that check at the beginning of the module methods, it should simply ignore anything that happens on an IPv4 transport and leave the SDP in-tact.

As for PJSIP supporting dual stack mode - there's really no sense in trying to do this when ICE is available. PJSIP's ICE implementation can and does support dual stack. If you can enable ICE on your server side as well, that should work for your use case.

Best,
Colin

On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi Colin,

We integrated the module as you suggested and it is working fine.
However it breaks when we connect the device with an IPV4 network. We understand that pjsip does't support dual stack mode. So what is the best way to do make the App work with both IPV6 and IPV4 networks.
Please suggest...

Thanks,
Ashok Narvaneni.


On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi Colin,

Thank you very much for detailed answer, I will try that patch and post my findings.

Thanks,
Ashok.

On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <***@gmail.com<mailto:***@gmail.com>> wrote:
Ashok,

What's almost certainly happening here is that the SDP returned from your server contains only IPv4 media addresses. When PJSIP goes to compare the SDP to local capabilities, it finds only IPv4 addresses for the remote endpoint, but can't find any local IPv4 interfaces. As a result, it thinks there's no way it can communicate with the remote server and fails.

I have been able to fix this with two steps:

1) Enable ICE negotiation on both your media server and PJSIP client. ICE is helpful here because it allows the two endpoints to communicate multiple candidate media addresses. This step *may* be optional, although I've never really tested without this.
2) Write a PJSIP module that intercepts incoming/outgoing SDPs to work around the NAT64 issue. There's an example of one of these on github<https://github.com/johanlantz/pj-nat64>, and I've written my own for my app (unfortunately can't share at this time). The general steps that need to be followed here are:

- Intercept on_tx and on_rx PJSIP events
- When sending an outgoing SDP, if signaling is connected over IPv6, then add an IPv4 address to the ICE candidates in the SDP (this step is optional, and depends on whether or not your server will explicitly reject an SDP that only contains IPv6 addresses)
- When receiving an incoming SDP, if signaling is connected over IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses, synthesize IPv6 addresses for them (by passing the IPv4 addresses to pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to a NAT64 network), and add the synthesized IPv6 addresses to the ICE candidates list

As long as this module is registered with a higher priority than the PJSIP transports module, the SDP will be rewritten before pjmedia actually parses the SDP. By the time it gets to the media stack, it will see your synthesized IPv6 addresses, which it can support, and should be able to establish a media connection.

Couple of tips here: don't underestimate the nuances of this issue. It's not necessarily a hard problem, but there are a lot of cases to consider. Once you solve the first issue, you then have the issue of what happens when the user changes networks during a call (i.e. their phone switches wifi networks, or off of wifi entirely). Additionally, if you're working on Android, you probably have this issue on Android as well, but Google as far as I know does not test apps on a NAT64 network like Apple does.

Apologies I can't be more specific at this time but I hope this points you in the right direction. I think it'd be great for PJSIP to include this in the core. NAT64 networks are likely to become more prevalent, and it would be considerably less work to simply add to the core than it would be to maintain a separate module.

Best,
Colin

On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi,

We are trying to connect to IPV4 server from our pjsip ios app with NAT64.
We can able to register with the server successfully But when we make calls their is no audio and call disconnects.
Below is the error.

19:39:43.256 pjsua_media.c .....Call 1: updating media..

19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp() failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)

19:39:43.257 pjsua_media.c ......Error updating media call01:0: Unsupported address family (PJ_EAFNOTSUP)

19:39:43.257 pjsua_media.c ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1: Unsupported address family (PJ_EAFNOTSUP)

19:39:43.257 pjsua_media.c ......Error updating media call01:1: Unsupported address family (PJ_EAFNOTSUP)

19:39:43.257 pjsua_call.c .....Unable to create media session: No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA) [status=220048]

19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:

What could be wrong? Can someone please help me on this.

Thanks,

Ashok Narvaneni.




_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org



_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org




_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org



_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org



_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
***@lists.pjsip.org<mailto:***@lists.pjsip.org>
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
Colin Morelli
2017-04-05 13:17:25 UTC
Permalink
Can't help a whole lot here since I'm not using registrations at all.

Couple of options off the top of my head:
- If enabling STUN in the PJSIP client is a possibility, I believe PJSIP
can resolve its actual address using STUN before constructing a contact
header and registering. This would not require you to change the Freeswitch
instances at all, but it would require you to have some kind of STUN server
you can use (for testing you can probably just hit Google's public STUN
servers but I have no idea if this is frowned upon by them or not).

- Alternatively, I believe there is a setting you can configure in
Freeswitch to ignore the contact header and always use the actual remote
address of the registration request. This would be a better question for
the Freeswitch mailing list, but probably if you look through their guides
on NAT you'll find something here. (Effectively, this is the same thing as
a client device trying to register with a private IPv4 address - either way
the contact header can't be trusted and the FS instance should use actual
available network information)

Best,
Colin

On Wed, Apr 5, 2017 at 8:49 AM, JOHAN LANTZ <***@telefonica.com>
wrote:

> For this problem I really do not know. I think our system does not pay
> that much attention to the Contact header but simply connects the
> registered device with the TCP/TLS socket used.
>
> I doubt there is anything missing on the client side if you simply does
> not receive the INVITE. Are other packets reaching the device? MESSAGE,
> keep-alive, etc?
>
> Johan
>
> From: pjsip on behalf of Ashok Narvaneni
> Reply-To: pjsip list
> Date: Wednesday, 5 April 2017 at 14:40
>
> To: pjsip list
> Subject: Re: [pjsip] NAT64 ios issue
>
> Thank you very much Colin and Johan for your help.
>
> We have made some good progress. Below is the current status.
> IPV4 - Phone register successfully, both Incoming and outgoing calls are
> working fine.
> IPV6 - Phone register successfully, outgoing calls are working fine but
> when some one dial the extension of the phone under IPV6, FreeSwitch server
> doesn't send the INVITE to the phone .
>
> Below is the register packet received on the server. Is there any other
> change we need to make on the app or Is that a FreeSwitch issue. Contact
> header have IPV6 address.
>
> REGISTER sip:xxxxxx.xxx;transport=TCP SIP/2.0
> Via: SIP/2.0/TCP [2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;rport;branch=
> z9hG4bKPjq-wL2PpL4k0klpjECGxQ7duSoDQPzA6-;alias
> Max-Forwards: 70
> From: <sip:***@xxxxxx.xxx>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
> To: <sip:***@xxxxxx.xxx>
> Call-ID: rQmIvhvfa8krjErV-bKQTnDcsfK79INU
> CSeq: 57007 REGISTER
> User-Agent: SIPUA-1.0 iOS-10.0.1/arm-iPhone8,1/iOS-SDK
> Supported: outbound, path
> Contact: <sip:103@[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;
> transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:
> 00000000-0000-0000-0000-0000fea119f6>"
> Expires: 60
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
> REFER, MESSAGE, OPTIONS
> Content-Length: 0
>
> Thanks,
> Ashok Narvaneni.
>
> On Tue, Apr 4, 2017 at 8:15 PM, JOHAN LANTZ <***@telefonica.com>
> wrote:
>
>> Hi Ashok
>>
>> Glad the module is more or less doing the job for you. As you can see in
>> the README.md file on GitHub under bullet 2, there is an example on how you
>> can activate this only when connecting to a IPv6 network. Then IPv4
>> continues to work as it has always done. Just hook it into the
>> on_registration callback from pjsip and I think you will be fine.
>>
>> Johan
>>
>> From: pjsip on behalf of Ashok Narvaneni
>> Reply-To: pjsip list
>> Date: Tuesday, 4 April 2017 at 16:36
>> To: pjsip list
>> Subject: Re: [pjsip] NAT64 ios issue
>>
>> Hi Colin,
>>
>> Thanks again for your kind reply.
>> We will make the changes and post our findings.
>> Unfortunately this server is provided by our client which does't have ICE
>> support.
>>
>> Thanks,
>> Ashok Narvaneni.
>>
>> On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com>
>> wrote:
>>
>>> Ahsok,
>>>
>>> This is one of the reasons I had written my own module (well, that and
>>> supporting ICE). The module I linked does not perform any checks about the
>>> current connection to the SIP server. Among other things, one of the
>>> additional things my modules does is only operate when connected to the
>>> signaling server via IPv6. This can be accomplished by a simple check in
>>> the on_rx and on_tx methods, before touching the SDP:
>>>
>>> (tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
>>> == PJSIP_TRANSPORT_IPV6
>>>
>>> With that check at the beginning of the module methods, it should simply
>>> ignore anything that happens on an IPv4 transport and leave the SDP
>>> in-tact.
>>>
>>> As for PJSIP supporting dual stack mode - there's really no sense in
>>> trying to do this when ICE is available. PJSIP's ICE implementation can and
>>> does support dual stack. If you can enable ICE on your server side as well,
>>> that should work for your use case.
>>>
>>> Best,
>>> Colin
>>>
>>> On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <
>>> ***@gmail.com> wrote:
>>>
>>>> Hi Colin,
>>>>
>>>> We integrated the module as you suggested and it is working fine.
>>>> However it breaks when we connect the device with an IPV4 network. We
>>>> understand that pjsip does't support dual stack mode. So what is the best
>>>> way to do make the App work with both IPV6 and IPV4 networks.
>>>> Please suggest...
>>>>
>>>> Thanks,
>>>> Ashok Narvaneni.
>>>>
>>>>
>>>> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
>>>> ***@gmail.com> wrote:
>>>>
>>>>> Hi Colin,
>>>>>
>>>>> Thank you very much for detailed answer, I will try that patch and
>>>>> post my findings.
>>>>>
>>>>> Thanks,
>>>>> Ashok.
>>>>>
>>>>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <
>>>>> ***@gmail.com> wrote:
>>>>>
>>>>>> Ashok,
>>>>>>
>>>>>> What's almost certainly happening here is that the SDP returned from
>>>>>> your server contains only IPv4 media addresses. When PJSIP goes to compare
>>>>>> the SDP to local capabilities, it finds only IPv4 addresses for the remote
>>>>>> endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
>>>>>> there's no way it can communicate with the remote server and fails.
>>>>>>
>>>>>> I have been able to fix this with two steps:
>>>>>>
>>>>>> 1) Enable ICE negotiation on both your media server and PJSIP
>>>>>> client. ICE is helpful here because it allows the two endpoints to
>>>>>> communicate multiple candidate media addresses. This step *may* be
>>>>>> optional, although I've never really tested without this.
>>>>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to
>>>>>> work around the NAT64 issue. There's an example of one of these on
>>>>>> github <https://github.com/johanlantz/pj-nat64>, and I've written my
>>>>>> own for my app (unfortunately can't share at this time). The general steps
>>>>>> that need to be followed here are:
>>>>>>
>>>>>> - Intercept on_tx and on_rx PJSIP events
>>>>>> - When sending an outgoing SDP, if signaling is connected over IPv6,
>>>>>> then add an IPv4 address to the ICE candidates in the SDP (this step is
>>>>>> optional, and depends on whether or not your server will explicitly reject
>>>>>> an SDP that only contains IPv6 addresses)
>>>>>> - When receiving an incoming SDP, if signaling is connected over
>>>>>> IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>>>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>>>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>>>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>>>>> candidates list
>>>>>>
>>>>>> As long as this module is registered with a higher priority than the
>>>>>> PJSIP transports module, the SDP will be rewritten before pjmedia actually
>>>>>> parses the SDP. By the time it gets to the media stack, it will see your
>>>>>> synthesized IPv6 addresses, which it can support, and should be able to
>>>>>> establish a media connection.
>>>>>>
>>>>>> Couple of tips here: don't underestimate the nuances of this issue.
>>>>>> It's not necessarily a *hard *problem, but there are a lot of cases
>>>>>> to consider. Once you solve the first issue, you then have the issue of
>>>>>> what happens when the user changes networks during a call (i.e. their phone
>>>>>> switches wifi networks, or off of wifi entirely). Additionally, if you're
>>>>>> working on Android, you probably have this issue on Android as well, but
>>>>>> Google as far as I know does not test apps on a NAT64 network like Apple
>>>>>> does.
>>>>>>
>>>>>> Apologies I can't be more specific at this time but I hope this
>>>>>> points you in the right direction. I think it'd be great for PJSIP to
>>>>>> include this in the core. NAT64 networks are likely to become more
>>>>>> prevalent, and it would be considerably less work to simply add to the core
>>>>>> than it would be to maintain a separate module.
>>>>>>
>>>>>> Best,
>>>>>> Colin
>>>>>>
>>>>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>>>>> ***@gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We are trying to connect to IPV4 server from our pjsip ios app with
>>>>>>> NAT64.
>>>>>>> We can able to register with the server successfully But when we
>>>>>>> make calls their is no audio and call disconnects.
>>>>>>> Below is the error.
>>>>>>>
>>>>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>>>>
>>>>>>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp()
>>>>>>> failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_media.c
>>>>>>> ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1:
>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_call.c .....Unable to create media session:
>>>>>>> No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>>>>> [status=220048]*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>>>>
>>>>>>> What could be wrong? Can someone please help me on this.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ashok Narvaneni.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>
>>>>>>> pjsip mailing list
>>>>>>> ***@lists.pjsip.org
>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>
>>>>>> pjsip mailing list
>>>>>> ***@lists.pjsip.org
>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> ***@lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> ***@lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
Ashok Narvaneni
2017-04-06 14:23:11 UTC
Permalink
Thanks for the reply Colin.

We tried the modification in FS. It's worked fine.

Thanks,
Ashok Narvaneni.

On Wed, Apr 5, 2017 at 6:47 PM, Colin Morelli <***@gmail.com>
wrote:

> Can't help a whole lot here since I'm not using registrations at all.
>
> Couple of options off the top of my head:
> - If enabling STUN in the PJSIP client is a possibility, I believe PJSIP
> can resolve its actual address using STUN before constructing a contact
> header and registering. This would not require you to change the Freeswitch
> instances at all, but it would require you to have some kind of STUN server
> you can use (for testing you can probably just hit Google's public STUN
> servers but I have no idea if this is frowned upon by them or not).
>
> - Alternatively, I believe there is a setting you can configure in
> Freeswitch to ignore the contact header and always use the actual remote
> address of the registration request. This would be a better question for
> the Freeswitch mailing list, but probably if you look through their guides
> on NAT you'll find something here. (Effectively, this is the same thing as
> a client device trying to register with a private IPv4 address - either way
> the contact header can't be trusted and the FS instance should use actual
> available network information)
>
> Best,
> Colin
>
> On Wed, Apr 5, 2017 at 8:49 AM, JOHAN LANTZ <***@telefonica.com>
> wrote:
>
>> For this problem I really do not know. I think our system does not pay
>> that much attention to the Contact header but simply connects the
>> registered device with the TCP/TLS socket used.
>>
>> I doubt there is anything missing on the client side if you simply does
>> not receive the INVITE. Are other packets reaching the device? MESSAGE,
>> keep-alive, etc?
>>
>> Johan
>>
>> From: pjsip on behalf of Ashok Narvaneni
>> Reply-To: pjsip list
>> Date: Wednesday, 5 April 2017 at 14:40
>>
>> To: pjsip list
>> Subject: Re: [pjsip] NAT64 ios issue
>>
>> Thank you very much Colin and Johan for your help.
>>
>> We have made some good progress. Below is the current status.
>> IPV4 - Phone register successfully, both Incoming and outgoing calls are
>> working fine.
>> IPV6 - Phone register successfully, outgoing calls are working fine but
>> when some one dial the extension of the phone under IPV6, FreeSwitch server
>> doesn't send the INVITE to the phone .
>>
>> Below is the register packet received on the server. Is there any other
>> change we need to make on the app or Is that a FreeSwitch issue. Contact
>> header have IPV6 address.
>>
>> REGISTER sip:xxxxxx.xxx;transport=TCP SIP/2.0
>> Via: SIP/2.0/TCP [2001:2::aab1:dc80:49bb:fedc:3
>> c1b]:63025;rport;branch=z9hG4bKPjq-wL2PpL4k0klpjECGxQ7duSoDQPzA6-;alias
>> Max-Forwards: 70
>> From: <sip:***@xxxxxx.xxx>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
>> To: <sip:***@xxxxxx.xxx>
>> Call-ID: rQmIvhvfa8krjErV-bKQTnDcsfK79INU
>> CSeq: 57007 REGISTER
>> User-Agent: SIPUA-1.0 iOS-10.0.1/arm-iPhone8,1/iOS-SDK
>> Supported: outbound, path
>> Contact: <sip:103@[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;transport=
>> TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-
>> 0000-0000-0000-0000fea119f6>"
>> Expires: 60
>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
>> REFER, MESSAGE, OPTIONS
>> Content-Length: 0
>>
>> Thanks,
>> Ashok Narvaneni.
>>
>> On Tue, Apr 4, 2017 at 8:15 PM, JOHAN LANTZ <***@telefonica.com>
>> wrote:
>>
>>> Hi Ashok
>>>
>>> Glad the module is more or less doing the job for you. As you can see in
>>> the README.md file on GitHub under bullet 2, there is an example on how you
>>> can activate this only when connecting to a IPv6 network. Then IPv4
>>> continues to work as it has always done. Just hook it into the
>>> on_registration callback from pjsip and I think you will be fine.
>>>
>>> Johan
>>>
>>> From: pjsip on behalf of Ashok Narvaneni
>>> Reply-To: pjsip list
>>> Date: Tuesday, 4 April 2017 at 16:36
>>> To: pjsip list
>>> Subject: Re: [pjsip] NAT64 ios issue
>>>
>>> Hi Colin,
>>>
>>> Thanks again for your kind reply.
>>> We will make the changes and post our findings.
>>> Unfortunately this server is provided by our client which does't have
>>> ICE support.
>>>
>>> Thanks,
>>> Ashok Narvaneni.
>>>
>>> On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com>
>>> wrote:
>>>
>>>> Ahsok,
>>>>
>>>> This is one of the reasons I had written my own module (well, that and
>>>> supporting ICE). The module I linked does not perform any checks about the
>>>> current connection to the SIP server. Among other things, one of the
>>>> additional things my modules does is only operate when connected to the
>>>> signaling server via IPv6. This can be accomplished by a simple check in
>>>> the on_rx and on_tx methods, before touching the SDP:
>>>>
>>>> (tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
>>>> == PJSIP_TRANSPORT_IPV6
>>>>
>>>> With that check at the beginning of the module methods, it should
>>>> simply ignore anything that happens on an IPv4 transport and leave the SDP
>>>> in-tact.
>>>>
>>>> As for PJSIP supporting dual stack mode - there's really no sense in
>>>> trying to do this when ICE is available. PJSIP's ICE implementation can and
>>>> does support dual stack. If you can enable ICE on your server side as well,
>>>> that should work for your use case.
>>>>
>>>> Best,
>>>> Colin
>>>>
>>>> On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <
>>>> ***@gmail.com> wrote:
>>>>
>>>>> Hi Colin,
>>>>>
>>>>> We integrated the module as you suggested and it is working fine.
>>>>> However it breaks when we connect the device with an IPV4 network. We
>>>>> understand that pjsip does't support dual stack mode. So what is the best
>>>>> way to do make the App work with both IPV6 and IPV4 networks.
>>>>> Please suggest...
>>>>>
>>>>> Thanks,
>>>>> Ashok Narvaneni.
>>>>>
>>>>>
>>>>> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
>>>>> ***@gmail.com> wrote:
>>>>>
>>>>>> Hi Colin,
>>>>>>
>>>>>> Thank you very much for detailed answer, I will try that patch and
>>>>>> post my findings.
>>>>>>
>>>>>> Thanks,
>>>>>> Ashok.
>>>>>>
>>>>>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <
>>>>>> ***@gmail.com> wrote:
>>>>>>
>>>>>>> Ashok,
>>>>>>>
>>>>>>> What's almost certainly happening here is that the SDP returned from
>>>>>>> your server contains only IPv4 media addresses. When PJSIP goes to compare
>>>>>>> the SDP to local capabilities, it finds only IPv4 addresses for the remote
>>>>>>> endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
>>>>>>> there's no way it can communicate with the remote server and fails.
>>>>>>>
>>>>>>> I have been able to fix this with two steps:
>>>>>>>
>>>>>>> 1) Enable ICE negotiation on both your media server and PJSIP
>>>>>>> client. ICE is helpful here because it allows the two endpoints to
>>>>>>> communicate multiple candidate media addresses. This step *may* be
>>>>>>> optional, although I've never really tested without this.
>>>>>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to
>>>>>>> work around the NAT64 issue. There's an example of one of these on
>>>>>>> github <https://github.com/johanlantz/pj-nat64>, and I've written
>>>>>>> my own for my app (unfortunately can't share at this time). The general
>>>>>>> steps that need to be followed here are:
>>>>>>>
>>>>>>> - Intercept on_tx and on_rx PJSIP events
>>>>>>> - When sending an outgoing SDP, if signaling is connected over
>>>>>>> IPv6, then add an IPv4 address to the ICE candidates in the SDP (this step
>>>>>>> is optional, and depends on whether or not your server will explicitly
>>>>>>> reject an SDP that only contains IPv6 addresses)
>>>>>>> - When receiving an incoming SDP, if signaling is connected over
>>>>>>> IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>>>>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>>>>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>>>>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>>>>>> candidates list
>>>>>>>
>>>>>>> As long as this module is registered with a higher priority than the
>>>>>>> PJSIP transports module, the SDP will be rewritten before pjmedia actually
>>>>>>> parses the SDP. By the time it gets to the media stack, it will see your
>>>>>>> synthesized IPv6 addresses, which it can support, and should be able to
>>>>>>> establish a media connection.
>>>>>>>
>>>>>>> Couple of tips here: don't underestimate the nuances of this issue.
>>>>>>> It's not necessarily a *hard *problem, but there are a lot of cases
>>>>>>> to consider. Once you solve the first issue, you then have the issue of
>>>>>>> what happens when the user changes networks during a call (i.e. their phone
>>>>>>> switches wifi networks, or off of wifi entirely). Additionally, if you're
>>>>>>> working on Android, you probably have this issue on Android as well, but
>>>>>>> Google as far as I know does not test apps on a NAT64 network like Apple
>>>>>>> does.
>>>>>>>
>>>>>>> Apologies I can't be more specific at this time but I hope this
>>>>>>> points you in the right direction. I think it'd be great for PJSIP to
>>>>>>> include this in the core. NAT64 networks are likely to become more
>>>>>>> prevalent, and it would be considerably less work to simply add to the core
>>>>>>> than it would be to maintain a separate module.
>>>>>>>
>>>>>>> Best,
>>>>>>> Colin
>>>>>>>
>>>>>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>>>>>> ***@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We are trying to connect to IPV4 server from our pjsip ios app with
>>>>>>>> NAT64.
>>>>>>>> We can able to register with the server successfully But when we
>>>>>>>> make calls their is no audio and call disconnects.
>>>>>>>> Below is the error.
>>>>>>>>
>>>>>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>>>>>
>>>>>>>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp()
>>>>>>>> failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>
>>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>
>>>>>>>> *19:39:43.257 pjsua_media.c
>>>>>>>> ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1:
>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>
>>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>
>>>>>>>> *19:39:43.257 pjsua_call.c .....Unable to create media session:
>>>>>>>> No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>>>>>> [status=220048]*
>>>>>>>>
>>>>>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>>>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>>>>>
>>>>>>>> What could be wrong? Can someone please help me on this.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Ashok Narvaneni.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>>
>>>>>>>> pjsip mailing list
>>>>>>>> ***@lists.pjsip.org
>>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>
>>>>>>> pjsip mailing list
>>>>>>> ***@lists.pjsip.org
>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Visit our blog: http://blog.pjsip.org
>>>>>
>>>>> pjsip mailing list
>>>>> ***@lists.pjsip.org
>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> ***@lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> ***@lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
Ashok Narvaneni
2017-04-12 12:23:27 UTC
Permalink
Thank you guys for your quick response,

Every thing is working fine with Audio call in IPV6.
But when i switch audio call to video call it's crashing in IPV6.

Thanks,
Ashok Narvaneni.

On Thu, Apr 6, 2017 at 7:53 PM, Ashok Narvaneni <***@gmail.com>
wrote:

> Thanks for the reply Colin.
>
> We tried the modification in FS. It's worked fine.
>
> Thanks,
> Ashok Narvaneni.
>
> On Wed, Apr 5, 2017 at 6:47 PM, Colin Morelli <***@gmail.com>
> wrote:
>
>> Can't help a whole lot here since I'm not using registrations at all.
>>
>> Couple of options off the top of my head:
>> - If enabling STUN in the PJSIP client is a possibility, I believe PJSIP
>> can resolve its actual address using STUN before constructing a contact
>> header and registering. This would not require you to change the Freeswitch
>> instances at all, but it would require you to have some kind of STUN server
>> you can use (for testing you can probably just hit Google's public STUN
>> servers but I have no idea if this is frowned upon by them or not).
>>
>> - Alternatively, I believe there is a setting you can configure in
>> Freeswitch to ignore the contact header and always use the actual remote
>> address of the registration request. This would be a better question for
>> the Freeswitch mailing list, but probably if you look through their guides
>> on NAT you'll find something here. (Effectively, this is the same thing as
>> a client device trying to register with a private IPv4 address - either way
>> the contact header can't be trusted and the FS instance should use actual
>> available network information)
>>
>> Best,
>> Colin
>>
>> On Wed, Apr 5, 2017 at 8:49 AM, JOHAN LANTZ <***@telefonica.com>
>> wrote:
>>
>>> For this problem I really do not know. I think our system does not pay
>>> that much attention to the Contact header but simply connects the
>>> registered device with the TCP/TLS socket used.
>>>
>>> I doubt there is anything missing on the client side if you simply does
>>> not receive the INVITE. Are other packets reaching the device? MESSAGE,
>>> keep-alive, etc?
>>>
>>> Johan
>>>
>>> From: pjsip on behalf of Ashok Narvaneni
>>> Reply-To: pjsip list
>>> Date: Wednesday, 5 April 2017 at 14:40
>>>
>>> To: pjsip list
>>> Subject: Re: [pjsip] NAT64 ios issue
>>>
>>> Thank you very much Colin and Johan for your help.
>>>
>>> We have made some good progress. Below is the current status.
>>> IPV4 - Phone register successfully, both Incoming and outgoing calls are
>>> working fine.
>>> IPV6 - Phone register successfully, outgoing calls are working fine but
>>> when some one dial the extension of the phone under IPV6, FreeSwitch server
>>> doesn't send the INVITE to the phone .
>>>
>>> Below is the register packet received on the server. Is there any other
>>> change we need to make on the app or Is that a FreeSwitch issue. Contact
>>> header have IPV6 address.
>>>
>>> REGISTER sip:xxxxxx.xxx;transport=TCP SIP/2.0
>>> Via: SIP/2.0/TCP [2001:2::aab1:dc80:49bb:fedc:3
>>> c1b]:63025;rport;branch=z9hG4bKPjq-wL2PpL4k0klpjECGxQ7duSoDQPzA6-;alias
>>> Max-Forwards: 70
>>> From: <sip:***@xxxxxx.xxx>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
>>> To: <sip:***@xxxxxx.xxx>
>>> Call-ID: rQmIvhvfa8krjErV-bKQTnDcsfK79INU
>>> CSeq: 57007 REGISTER
>>> User-Agent: SIPUA-1.0 iOS-10.0.1/arm-iPhone8,1/iOS-SDK
>>> Supported: outbound, path
>>> Contact: <sip:103@[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;transport=
>>> TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-
>>> 0000-0000-0000fea119f6>"
>>> Expires: 60
>>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
>>> REFER, MESSAGE, OPTIONS
>>> Content-Length: 0
>>>
>>> Thanks,
>>> Ashok Narvaneni.
>>>
>>> On Tue, Apr 4, 2017 at 8:15 PM, JOHAN LANTZ <***@telefonica.com>
>>> wrote:
>>>
>>>> Hi Ashok
>>>>
>>>> Glad the module is more or less doing the job for you. As you can see
>>>> in the README.md file on GitHub under bullet 2, there is an example on how
>>>> you can activate this only when connecting to a IPv6 network. Then IPv4
>>>> continues to work as it has always done. Just hook it into the
>>>> on_registration callback from pjsip and I think you will be fine.
>>>>
>>>> Johan
>>>>
>>>> From: pjsip on behalf of Ashok Narvaneni
>>>> Reply-To: pjsip list
>>>> Date: Tuesday, 4 April 2017 at 16:36
>>>> To: pjsip list
>>>> Subject: Re: [pjsip] NAT64 ios issue
>>>>
>>>> Hi Colin,
>>>>
>>>> Thanks again for your kind reply.
>>>> We will make the changes and post our findings.
>>>> Unfortunately this server is provided by our client which does't have
>>>> ICE support.
>>>>
>>>> Thanks,
>>>> Ashok Narvaneni.
>>>>
>>>> On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com>
>>>> wrote:
>>>>
>>>>> Ahsok,
>>>>>
>>>>> This is one of the reasons I had written my own module (well, that and
>>>>> supporting ICE). The module I linked does not perform any checks about the
>>>>> current connection to the SIP server. Among other things, one of the
>>>>> additional things my modules does is only operate when connected to the
>>>>> signaling server via IPv6. This can be accomplished by a simple check in
>>>>> the on_rx and on_tx methods, before touching the SDP:
>>>>>
>>>>> (tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
>>>>> == PJSIP_TRANSPORT_IPV6
>>>>>
>>>>> With that check at the beginning of the module methods, it should
>>>>> simply ignore anything that happens on an IPv4 transport and leave the SDP
>>>>> in-tact.
>>>>>
>>>>> As for PJSIP supporting dual stack mode - there's really no sense in
>>>>> trying to do this when ICE is available. PJSIP's ICE implementation can and
>>>>> does support dual stack. If you can enable ICE on your server side as well,
>>>>> that should work for your use case.
>>>>>
>>>>> Best,
>>>>> Colin
>>>>>
>>>>> On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <
>>>>> ***@gmail.com> wrote:
>>>>>
>>>>>> Hi Colin,
>>>>>>
>>>>>> We integrated the module as you suggested and it is working fine.
>>>>>> However it breaks when we connect the device with an IPV4 network. We
>>>>>> understand that pjsip does't support dual stack mode. So what is the best
>>>>>> way to do make the App work with both IPV6 and IPV4 networks.
>>>>>> Please suggest...
>>>>>>
>>>>>> Thanks,
>>>>>> Ashok Narvaneni.
>>>>>>
>>>>>>
>>>>>> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
>>>>>> ***@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Colin,
>>>>>>>
>>>>>>> Thank you very much for detailed answer, I will try that patch and
>>>>>>> post my findings.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ashok.
>>>>>>>
>>>>>>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <
>>>>>>> ***@gmail.com> wrote:
>>>>>>>
>>>>>>>> Ashok,
>>>>>>>>
>>>>>>>> What's almost certainly happening here is that the SDP returned
>>>>>>>> from your server contains only IPv4 media addresses. When PJSIP goes to
>>>>>>>> compare the SDP to local capabilities, it finds only IPv4 addresses for the
>>>>>>>> remote endpoint, but can't find any local IPv4 interfaces. As a result, it
>>>>>>>> thinks there's no way it can communicate with the remote server and fails.
>>>>>>>>
>>>>>>>> I have been able to fix this with two steps:
>>>>>>>>
>>>>>>>> 1) Enable ICE negotiation on both your media server and PJSIP
>>>>>>>> client. ICE is helpful here because it allows the two endpoints to
>>>>>>>> communicate multiple candidate media addresses. This step *may* be
>>>>>>>> optional, although I've never really tested without this.
>>>>>>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to
>>>>>>>> work around the NAT64 issue. There's an example of one of these on
>>>>>>>> github <https://github.com/johanlantz/pj-nat64>, and I've written
>>>>>>>> my own for my app (unfortunately can't share at this time). The general
>>>>>>>> steps that need to be followed here are:
>>>>>>>>
>>>>>>>> - Intercept on_tx and on_rx PJSIP events
>>>>>>>> - When sending an outgoing SDP, if signaling is connected over
>>>>>>>> IPv6, then add an IPv4 address to the ICE candidates in the SDP (this step
>>>>>>>> is optional, and depends on whether or not your server will explicitly
>>>>>>>> reject an SDP that only contains IPv6 addresses)
>>>>>>>> - When receiving an incoming SDP, if signaling is connected over
>>>>>>>> IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>>>>>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>>>>>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>>>>>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>>>>>>> candidates list
>>>>>>>>
>>>>>>>> As long as this module is registered with a higher priority than
>>>>>>>> the PJSIP transports module, the SDP will be rewritten before pjmedia
>>>>>>>> actually parses the SDP. By the time it gets to the media stack, it will
>>>>>>>> see your synthesized IPv6 addresses, which it can support, and should be
>>>>>>>> able to establish a media connection.
>>>>>>>>
>>>>>>>> Couple of tips here: don't underestimate the nuances of this issue.
>>>>>>>> It's not necessarily a *hard *problem, but there are a lot of
>>>>>>>> cases to consider. Once you solve the first issue, you then have the issue
>>>>>>>> of what happens when the user changes networks during a call (i.e. their
>>>>>>>> phone switches wifi networks, or off of wifi entirely). Additionally, if
>>>>>>>> you're working on Android, you probably have this issue on Android as well,
>>>>>>>> but Google as far as I know does not test apps on a NAT64 network like
>>>>>>>> Apple does.
>>>>>>>>
>>>>>>>> Apologies I can't be more specific at this time but I hope this
>>>>>>>> points you in the right direction. I think it'd be great for PJSIP to
>>>>>>>> include this in the core. NAT64 networks are likely to become more
>>>>>>>> prevalent, and it would be considerably less work to simply add to the core
>>>>>>>> than it would be to maintain a separate module.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Colin
>>>>>>>>
>>>>>>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> We are trying to connect to IPV4 server from our pjsip ios app
>>>>>>>>> with NAT64.
>>>>>>>>> We can able to register with the server successfully But when we
>>>>>>>>> make calls their is no audio and call disconnects.
>>>>>>>>> Below is the error.
>>>>>>>>>
>>>>>>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>>>>>>
>>>>>>>>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp()
>>>>>>>>> failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>
>>>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>
>>>>>>>>> *19:39:43.257 pjsua_media.c
>>>>>>>>> ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1:
>>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>
>>>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>
>>>>>>>>> *19:39:43.257 pjsua_call.c .....Unable to create media session:
>>>>>>>>> No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>>>>>>> [status=220048]*
>>>>>>>>>
>>>>>>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>>>>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>>>>>>
>>>>>>>>> What could be wrong? Can someone please help me on this.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Ashok Narvaneni.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>>>
>>>>>>>>> pjsip mailing list
>>>>>>>>> ***@lists.pjsip.org
>>>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>>
>>>>>>>> pjsip mailing list
>>>>>>>> ***@lists.pjsip.org
>>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>
>>>>>> pjsip mailing list
>>>>>> ***@lists.pjsip.org
>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Visit our blog: http://blog.pjsip.org
>>>>>
>>>>> pjsip mailing list
>>>>> ***@lists.pjsip.org
>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> ***@lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> ***@lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
Ashok Narvaneni
2017-04-17 11:19:34 UTC
Permalink
Hi,

As mentioned in my previous mail i still have crash issue with video on
IPV6. Can some one please take a look at the below logs and provide some
suggestions.

*2017-04-17 15:33:38.974082+0530 SIPX[3190:953743] -[UConnect
changedAudioCallToVideoCall:]*

*15:33:38.974 pjsua_call.c !Sending re-INVITE on call 0*

*15:33:38.974 pjsua_media.c .Call 0: re-initializing media..*

*15:33:38.975 pjsua_media.c ..RTP socket reachable at
[2001:2::aab1:dd37:c606:94a2:f50d]:4002*

*15:33:38.975 pjsua_media.c ..RTCP socket reachable at
[2001:2::aab1:dd37:c606:94a2:f50d]:4003*

*15:33:38.975 pjsua_media.c ..Media index 0 selected for audio call 0*

*15:33:38.975 pjsua_core.c ....TX 1378 bytes Request msg
INVITE/cseq=11133 (tdta0x150920000) to TCP 2001:2:0:1baa::4225:2ca6:5060:*

*INVITE sip:103@[2001:2:0:1baa::4225:2ca6]:5060;transport=tcp SIP/2.0*


*Via: SIP/2.0/TCP
xxxxxx.xxx:42312;rport;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*


*Max-Forwards: 70*


*From: sip:***@xxxxxx.xxx;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*


*To: sip:***@xxxxxx.xxx;tag=jZ4Be8mcX701c*


*Contact:
<sip:104@[2001:2::aab1:dd37:c606:94a2:f50d]:51419;transport=TCP;ob>*


*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*


*CSeq: 11133 INVITE*


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


*Supported: replaces, 100rel, norefersub*


*User-Agent: SIPXUA-1.0 iOS-10.3.1/arm-iPhone8,4/iOS-SDK*


*Content-Type: application/sdp*


*Content-Length: 668*




*v=0*


*o=- 3701412213 3701412214 IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*


*s=pjmedia*


*b=AS:352*


*t=0 0*


*a=X-nat:0*


*m=audio 4000 RTP/AVP 98 97 0 99 9 96*


*c=IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*


*b=TIAS:64000*


*a=rtcp:4001 IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*


*a=sendrecv*


*a=rtpmap:98 speex/16000*


*a=rtpmap:97 speex/8000*


*a=rtpmap:0 PCMU/8000*


*a=rtpmap:99 speex/32000*


*a=rtpmap:9 G722/8000*


*a=rtpmap:96 telephone-event/8000*


*a=fmtp:96 0-16*


*m=video 4002 RTP/AVP 97*


*c=IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*


*b=TIAS:256000*


*a=rtcp:4003 IN IP6 2001:2::aab1:dd37:c606:94a2:f50d*


*a=sendrecv*


*a=rtpmap:97 H264/90000*


*a=fmtp:97 profile-level-id=42e01e; packetization-mode=1*



*--end msg--*

*15:33:38.979 SIPXUA unMuteCall Called*

*2017-04-17 15:33:38.984284+0530 SIPX[3190:953743] -[UConnect speakerOn]*

*15:33:39.236 pj_nat64.c !.ipv6_mod_on_rx*

*15:33:39.236 pj_nat64.c .Incoming INVITE or 200 OK. If they contain
IPv4 addresses, we need to change to ipv6*

*15:33:39.236 pj_nat64.c .**********Incoming INVITE or 200 with IPv4
address**************

*15:33:39.236 pj_nat64.c .SIP/2.0 100 Trying*


*Via: SIP/2.0/TCP
183.82.117.54:42312;rport=42312;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*


*From: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*


*To: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*


*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*


*CSeq: 11133 INVITE*


*User-Agent: Vinci-PBX*


*Content-Length: 0*





*15:33:39.236 pj_nat64.c
.****************************************************************

*15:33:39.236 pj_nat64.c .Scanner syntax error at *

*15:33:39.236 pj_nat64.c .Error: Parsing of the incoming INVITE/200 OK
failed at . Leave incoming buffer as is*

*15:33:39.236 pjsua_core.c .RX 365 bytes Response msg
100/INVITE/cseq=11133 (rdata0x150881330) from TCP
2001:2:0:1baa::4225:2ca6:5060:*

*SIP/2.0 100 Trying*


*Via: SIP/2.0/TCP
183.82.117.54:42312;rport=42312;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*


*From: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*


*To: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*


*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*


*CSeq: 11133 INVITE*


*User-Agent: Vinci-PBX*


*Content-Length: 0*





*--end msg--*

*15:33:39.239 pj_nat64.c .ipv6_mod_on_rx*

*15:33:39.239 pj_nat64.c .Incoming INVITE or 200 OK. If they contain
IPv4 addresses, we need to change to ipv6*

*15:33:39.239 pj_nat64.c .**********Incoming INVITE or 200 with IPv4
address**************

*15:33:39.239 pj_nat64.c .SIP/2.0 200 OK*


*Via: SIP/2.0/TCP
183.82.117.54:42312;rport=42312;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*


*From: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*


*To: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*


*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*


*CSeq: 11133 INVITE*


*Contact: <sip:***@xxxxxx.xxx:5060;transport=tcp>*


*User-Agent: Vinci-PBX*


*Accept: application/sdp*


*Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE*


*Supported: timer, path, replaces*


*Session-Expires: 120;refresher=uas*


*Content-Type: application/sdp*


*Content-Disposition: session*


*Content-Length: 358*




*v=0*


*o=FreeSWITCH 1492392842 1492392844 IN IP4 xxxxxx.xxx*


*s=FreeSWITCH*


*c=IN IP4 xxxxxx.xxx*


*t=0 0*


*m=audio 29974 RTP/AVP 0 96*


*a=rtpmap:0 PCMU/8000*


*a=rtpmap:96 telephone-event/8000*


*a=fmtp:96 0-16*


*a=ptime:20*


*a=rtcp:29975 IN IP4 xxxxxx.xxx*


*m=video 17638 RTP/AVP 97*


*a=rtpmap:97 H264/90000*


*a=fmtp:97 profile-level-id=42e01e; packetization-mode=1*


*INFO sip:104@[2001:2::aab1:dd37:c606:94a2:f50d]:51419;transport=TCP;ob
SIP/2.0*


*Via: SIP/2.0/TCP xxxxxx.xxx;branch=z9hG4bKm0H32cN7F1c2p*


*Max-Forwards: 70*


*From: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*


*To: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*


*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*


*CSeq: 105875569 INFO*


*Contact: <sip:***@xxxxxx.xxx:5060;transport=tcp>*


*User-Agent: Vinci-PBX*


*Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE*


*Supported: timer, path, replaces*


*Content-Type: application/media_control+xml*


*Content-Length: 175*




*<?xml version="1.0" encoding="utf-8" ?>*

*<media_control>*

*<vc_primitive>*

*<to_encoder>*

*<picture_fast_update>*

*</picture_fast_update>*

*</to_encoder>*

*</vc_primitive>*

*</media_control>*

*15:33:39.243 pj_nat64.c
.****************************************************************

*15:33:39.243 pj_nat64.c .Extracted ip4 address as xxxxxx.xxx*

*15:33:39.255 pj_nat64.c .Extracted ip4 address as xxxxxx.xxx*

*15:33:39.258 pj_nat64.c .Extracted ip4 address as xxxxxx.xxx*

*2017-04-17 15:33:39.259449+0530 SIPX[3190:953743] audioSession active*

*15:33:39.277 pj_nat64.c .Scanner syntax error at *

*15:33:39.277 pj_nat64.c .Current Content-Length is: 358 and new
Content-Length is 1211 .*

*15:33:39.277 pj_nat64.c .Updated content length needs more bytes than
old one, we must do expand and copy. TODO*

*15:33:39.278 pj_nat64.c .We have successfully parsed the INVITE/200
OK until EOF. Replace rx buffer. pjsip will now print the modified rx
packet.*

*15:33:39.278 pj_nat64.c .Host in Contact header is xxxxxx.xxx*

*15:33:39.287 pjsua_core.c .RX 1892 bytes Response msg
200/INVITE/cseq=11133 (rdata0x150881330) from TCP
2001:2:0:1baa::4225:2ca6:5060:*

*SIP/2.0 200 OK*


*Via: SIP/2.0/TCP
183.82.117.54:42312;rport=42312;branch=z9hG4bKPjnrv2JR2dFTn9xPwITawyvkOSSkve.pob;alias*


*From: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*


*To: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*


*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*


*CSeq: 11133 INVITE*


*Contact: <sip:***@xxxxxx.xxx:5060;transport=tcp>*


*User-Agent: Vinci-PBX*


*Accept: application/sdp*


*Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE*


*Supported: timer, path, replaces*


*Session-Expires: 120;refresher=uas*


*Content-Type: application/sdp*


*Content-Disposition: session*


*Content-Length: 358*




*v=0*


*o=FreeSWITCH 1492392842 1492392844 IN IP6 2001:2:0:1baa::4225:2ca6*


*s=FreeSWITCH*


*c=IN IP6 2001:2:0:1baa::4225:2ca6*


*t=0 0*


*m=audio 29974 RTP/AVP 0 96*


*a=rtpmap:0 PCMU/8000*


*a=2017-04-17 15:33:39.290674+0530 SIPX[3190:953831] routeChangeReason :
AVAudioSessionRouteChangeReasonCategoryChange*

*2017-04-17 15:33:39.290933+0530 SIPX[3190:953831]
-[MTAnswerCallViewController audiRouteChanged:]*

*rtpmap:96 telephone-event/8000*


*a=fmtp:96 0-16*


*a=ptime:20*


*a=rtcp:29975 IN IP6 2001:2:0:1baa::4225:2ca6*


*m=video 17638 RTP/AVP 97*


*a=rtpmap:97 H264/90000*


*a=fmtp:97 profile-level-id=42e01e; packetization-mode=1*


*INFO sip:104@[2001:2::aab1:dd37:c606:94a2:f50d]:51419;transport=TCP;ob
SIP/2.0*


*Via: SIP/2.0/TCP xxxxxx.xxx;branch=z9hG4bKm0H32cN7F1c2p*


*Max-Forwards: 70*


*From: <sip:***@xxxxxx.xxx>;tag=jZ4Be8mcX701c*


*To: <sip:***@xxxxxx.xxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX*


*Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-*


*CSeq: 105875569 INFO*


*Contact: <sip:***@xxxxxx.xxx:5060;transport=tcp>*


*User-Agent: Vinci-PBX*


*Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE*


*Supported: timer, path, replaces*


*Content-Type: application/media_control+xml*


*Content-Length: 175*




*<?xml version="1.0" encoding="utf-8" ?>*

*<media_control>*

*<vc_primitive>*

*<to_encoder>*

*<picture_fast_update>*

*</picture_fast_update>*

*</to_encoder>*

*</vc_primitive>*

*</media_control>*

*--end msg--*

*15:33:39.301 sdp.c ....Error parsing SDP in line 15 col 0:
Success*

*Assertion failed: (ctx.last_error != PJ_SUCCESS), function
pjmedia_sdp_parse, file ../src/pjmedia/sdp.c, line 1349.*

Thanks.

On Wed, Apr 12, 2017 at 5:53 PM, Ashok Narvaneni <***@gmail.com>
wrote:

> Thank you guys for your quick response,
>
> Every thing is working fine with Audio call in IPV6.
> But when i switch audio call to video call it's crashing in IPV6.
>
> Thanks,
> Ashok Narvaneni.
>
> On Thu, Apr 6, 2017 at 7:53 PM, Ashok Narvaneni <***@gmail.com
> > wrote:
>
>> Thanks for the reply Colin.
>>
>> We tried the modification in FS. It's worked fine.
>>
>> Thanks,
>> Ashok Narvaneni.
>>
>> On Wed, Apr 5, 2017 at 6:47 PM, Colin Morelli <***@gmail.com>
>> wrote:
>>
>>> Can't help a whole lot here since I'm not using registrations at all.
>>>
>>> Couple of options off the top of my head:
>>> - If enabling STUN in the PJSIP client is a possibility, I believe
>>> PJSIP can resolve its actual address using STUN before constructing a
>>> contact header and registering. This would not require you to change the
>>> Freeswitch instances at all, but it would require you to have some kind of
>>> STUN server you can use (for testing you can probably just hit Google's
>>> public STUN servers but I have no idea if this is frowned upon by them or
>>> not).
>>>
>>> - Alternatively, I believe there is a setting you can configure in
>>> Freeswitch to ignore the contact header and always use the actual remote
>>> address of the registration request. This would be a better question for
>>> the Freeswitch mailing list, but probably if you look through their guides
>>> on NAT you'll find something here. (Effectively, this is the same thing as
>>> a client device trying to register with a private IPv4 address - either way
>>> the contact header can't be trusted and the FS instance should use actual
>>> available network information)
>>>
>>> Best,
>>> Colin
>>>
>>> On Wed, Apr 5, 2017 at 8:49 AM, JOHAN LANTZ <***@telefonica.com>
>>> wrote:
>>>
>>>> For this problem I really do not know. I think our system does not pay
>>>> that much attention to the Contact header but simply connects the
>>>> registered device with the TCP/TLS socket used.
>>>>
>>>> I doubt there is anything missing on the client side if you simply does
>>>> not receive the INVITE. Are other packets reaching the device? MESSAGE,
>>>> keep-alive, etc?
>>>>
>>>> Johan
>>>>
>>>> From: pjsip on behalf of Ashok Narvaneni
>>>> Reply-To: pjsip list
>>>> Date: Wednesday, 5 April 2017 at 14:40
>>>>
>>>> To: pjsip list
>>>> Subject: Re: [pjsip] NAT64 ios issue
>>>>
>>>> Thank you very much Colin and Johan for your help.
>>>>
>>>> We have made some good progress. Below is the current status.
>>>> IPV4 - Phone register successfully, both Incoming and outgoing calls
>>>> are working fine.
>>>> IPV6 - Phone register successfully, outgoing calls are working fine but
>>>> when some one dial the extension of the phone under IPV6, FreeSwitch server
>>>> doesn't send the INVITE to the phone .
>>>>
>>>> Below is the register packet received on the server. Is there any other
>>>> change we need to make on the app or Is that a FreeSwitch issue. Contact
>>>> header have IPV6 address.
>>>>
>>>> REGISTER sip:xxxxxx.xxx;transport=TCP SIP/2.0
>>>> Via: SIP/2.0/TCP [2001:2::aab1:dc80:49bb:fedc:3
>>>> c1b]:63025;rport;branch=z9hG4bKPjq-wL2PpL4k0klpjECGxQ7duSoDQPzA6-;alias
>>>> Max-Forwards: 70
>>>> From: <sip:***@xxxxxx.xxx>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
>>>> To: <sip:***@xxxxxx.xxx>
>>>> Call-ID: rQmIvhvfa8krjErV-bKQTnDcsfK79INU
>>>> CSeq: 57007 REGISTER
>>>> User-Agent: SIPUA-1.0 iOS-10.0.1/arm-iPhone8,1/iOS-SDK
>>>> Supported: outbound, path
>>>> Contact: <sip:103@[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;transport=
>>>> TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000
>>>> -0000-0000fea119f6>"
>>>> Expires: 60
>>>> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE,
>>>> NOTIFY, REFER, MESSAGE, OPTIONS
>>>> Content-Length: 0
>>>>
>>>> Thanks,
>>>> Ashok Narvaneni.
>>>>
>>>> On Tue, Apr 4, 2017 at 8:15 PM, JOHAN LANTZ <***@telefonica.com
>>>> > wrote:
>>>>
>>>>> Hi Ashok
>>>>>
>>>>> Glad the module is more or less doing the job for you. As you can see
>>>>> in the README.md file on GitHub under bullet 2, there is an example on how
>>>>> you can activate this only when connecting to a IPv6 network. Then IPv4
>>>>> continues to work as it has always done. Just hook it into the
>>>>> on_registration callback from pjsip and I think you will be fine.
>>>>>
>>>>> Johan
>>>>>
>>>>> From: pjsip on behalf of Ashok Narvaneni
>>>>> Reply-To: pjsip list
>>>>> Date: Tuesday, 4 April 2017 at 16:36
>>>>> To: pjsip list
>>>>> Subject: Re: [pjsip] NAT64 ios issue
>>>>>
>>>>> Hi Colin,
>>>>>
>>>>> Thanks again for your kind reply.
>>>>> We will make the changes and post our findings.
>>>>> Unfortunately this server is provided by our client which does't have
>>>>> ICE support.
>>>>>
>>>>> Thanks,
>>>>> Ashok Narvaneni.
>>>>>
>>>>> On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Ahsok,
>>>>>>
>>>>>> This is one of the reasons I had written my own module (well, that
>>>>>> and supporting ICE). The module I linked does not perform any checks about
>>>>>> the current connection to the SIP server. Among other things, one of the
>>>>>> additional things my modules does is only operate when connected to the
>>>>>> signaling server via IPv6. This can be accomplished by a simple check in
>>>>>> the on_rx and on_tx methods, before touching the SDP:
>>>>>>
>>>>>> (tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
>>>>>> == PJSIP_TRANSPORT_IPV6
>>>>>>
>>>>>> With that check at the beginning of the module methods, it should
>>>>>> simply ignore anything that happens on an IPv4 transport and leave the SDP
>>>>>> in-tact.
>>>>>>
>>>>>> As for PJSIP supporting dual stack mode - there's really no sense in
>>>>>> trying to do this when ICE is available. PJSIP's ICE implementation can and
>>>>>> does support dual stack. If you can enable ICE on your server side as well,
>>>>>> that should work for your use case.
>>>>>>
>>>>>> Best,
>>>>>> Colin
>>>>>>
>>>>>> On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <
>>>>>> ***@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Colin,
>>>>>>>
>>>>>>> We integrated the module as you suggested and it is working fine.
>>>>>>> However it breaks when we connect the device with an IPV4 network.
>>>>>>> We understand that pjsip does't support dual stack mode. So what is the
>>>>>>> best way to do make the App work with both IPV6 and IPV4 networks.
>>>>>>> Please suggest...
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ashok Narvaneni.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
>>>>>>> ***@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Colin,
>>>>>>>>
>>>>>>>> Thank you very much for detailed answer, I will try that patch and
>>>>>>>> post my findings.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ashok.
>>>>>>>>
>>>>>>>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <
>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Ashok,
>>>>>>>>>
>>>>>>>>> What's almost certainly happening here is that the SDP returned
>>>>>>>>> from your server contains only IPv4 media addresses. When PJSIP goes to
>>>>>>>>> compare the SDP to local capabilities, it finds only IPv4 addresses for the
>>>>>>>>> remote endpoint, but can't find any local IPv4 interfaces. As a result, it
>>>>>>>>> thinks there's no way it can communicate with the remote server and fails.
>>>>>>>>>
>>>>>>>>> I have been able to fix this with two steps:
>>>>>>>>>
>>>>>>>>> 1) Enable ICE negotiation on both your media server and PJSIP
>>>>>>>>> client. ICE is helpful here because it allows the two endpoints to
>>>>>>>>> communicate multiple candidate media addresses. This step *may* be
>>>>>>>>> optional, although I've never really tested without this.
>>>>>>>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to
>>>>>>>>> work around the NAT64 issue. There's an example of one of these
>>>>>>>>> on github <https://github.com/johanlantz/pj-nat64>, and I've
>>>>>>>>> written my own for my app (unfortunately can't share at this time). The
>>>>>>>>> general steps that need to be followed here are:
>>>>>>>>>
>>>>>>>>> - Intercept on_tx and on_rx PJSIP events
>>>>>>>>> - When sending an outgoing SDP, if signaling is connected over
>>>>>>>>> IPv6, then add an IPv4 address to the ICE candidates in the SDP (this step
>>>>>>>>> is optional, and depends on whether or not your server will explicitly
>>>>>>>>> reject an SDP that only contains IPv6 addresses)
>>>>>>>>> - When receiving an incoming SDP, if signaling is connected over
>>>>>>>>> IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>>>>>>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>>>>>>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>>>>>>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>>>>>>>> candidates list
>>>>>>>>>
>>>>>>>>> As long as this module is registered with a higher priority than
>>>>>>>>> the PJSIP transports module, the SDP will be rewritten before pjmedia
>>>>>>>>> actually parses the SDP. By the time it gets to the media stack, it will
>>>>>>>>> see your synthesized IPv6 addresses, which it can support, and should be
>>>>>>>>> able to establish a media connection.
>>>>>>>>>
>>>>>>>>> Couple of tips here: don't underestimate the nuances of this
>>>>>>>>> issue. It's not necessarily a *hard *problem, but there are a lot
>>>>>>>>> of cases to consider. Once you solve the first issue, you then have the
>>>>>>>>> issue of what happens when the user changes networks during a call (i.e.
>>>>>>>>> their phone switches wifi networks, or off of wifi entirely). Additionally,
>>>>>>>>> if you're working on Android, you probably have this issue on Android as
>>>>>>>>> well, but Google as far as I know does not test apps on a NAT64 network
>>>>>>>>> like Apple does.
>>>>>>>>>
>>>>>>>>> Apologies I can't be more specific at this time but I hope this
>>>>>>>>> points you in the right direction. I think it'd be great for PJSIP to
>>>>>>>>> include this in the core. NAT64 networks are likely to become more
>>>>>>>>> prevalent, and it would be considerably less work to simply add to the core
>>>>>>>>> than it would be to maintain a separate module.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Colin
>>>>>>>>>
>>>>>>>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>>>>>>>> ***@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> We are trying to connect to IPV4 server from our pjsip ios app
>>>>>>>>>> with NAT64.
>>>>>>>>>> We can able to register with the server successfully But when we
>>>>>>>>>> make calls their is no audio and call disconnects.
>>>>>>>>>> Below is the error.
>>>>>>>>>>
>>>>>>>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.256 pjsua_media.c
>>>>>>>>>> ......pjmedia_stream_info_from_sdp() failed for call_id 1 media 0:
>>>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media
>>>>>>>>>> call01:0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_media.c
>>>>>>>>>> ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1:
>>>>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media
>>>>>>>>>> call01:1: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_call.c .....Unable to create media
>>>>>>>>>> session: No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>>>>>>>> [status=220048]*
>>>>>>>>>>
>>>>>>>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>>>>>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>>>>>>>
>>>>>>>>>> What could be wrong? Can someone please help me on this.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Ashok Narvaneni.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>>>>
>>>>>>>>>> pjsip mailing list
>>>>>>>>>> ***@lists.pjsip.org
>>>>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>>>
>>>>>>>>> pjsip mailing list
>>>>>>>>> ***@lists.pjsip.org
>>>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>
>>>>>>> pjsip mailing list
>>>>>>> ***@lists.pjsip.org
>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>
>>>>>> pjsip mailing list
>>>>>> ***@lists.pjsip.org
>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Visit our blog: http://blog.pjsip.org
>>>>>
>>>>> pjsip mailing list
>>>>> ***@lists.pjsip.org
>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> ***@lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>
JOHAN LANTZ
2017-04-18 08:27:27 UTC
Permalink
Hi Ashok

I think you simply have to dig into the code and fix this yourself. I only implemented this for the audio case so probably multiple media lines are not managed at all.

/Johan


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Ashok Narvaneni
2017-04-18 11:03:33 UTC
Permalink
Thanks for the reply Johan. I will try this if i found any difficulties, I
will post my findings.

On Tue, Apr 18, 2017 at 1:57 PM, JOHAN LANTZ <***@telefonica.com>
wrote:

> Hi Ashok
>
> I think you simply have to dig into the code and fix this yourself. I only
> implemented this for the audio case so probably multiple media lines are
> not managed at all.
>
> /Johan
>
>
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
Girish Gopinath
2017-05-10 13:08:08 UTC
Permalink
Hi Johan:


Trying to make video work with IPv6, and we see that crash is happening when the condition if (strlen(new_content_len_buf) <= current_content_len.slen) fails. It prints the log "Updated content length needs more bytes than old one, we must do expand and copy. TODO". Could you please suggest ways of fixing this or elaborate on the log message "we must expand and copy"?


Any help with resolving this is highly appreciated.


Thank you,


Girish


________________________________
From: pjsip <pjsip-***@lists.pjsip.org> on behalf of JOHAN LANTZ <***@telefonica.com>
Sent: Tuesday, April 18, 2017 1:57 PM
To: pjsip list
Subject: Re: [pjsip] NAT64 ios issue

Hi Ashok

I think you simply have to dig into the code and fix this yourself. I only implemented this for the audio case so probably multiple media lines are not managed at all.

/Johan


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
JOHAN LANTZ
2017-05-10 13:30:54 UTC
Permalink
Could you send an example of the sdp you are processing?

I assume this simply means that previously your content length used for instance 3 chars, something like 980 and then after the manipulation content length is more than 1000 bytes meaning we need 4 characters instead of 3. IIRC my sdpÂŽs were quite far away from the limit so I added that scenario as a corner case that I did not implement. I think you will be able to fix it yourself if you spend some time on it. I am going to spend a little time on this code this week but I can not promise I have time to add this scenario so I suggest you start by trying to fix it yourself (and contribute the fix back to GitHub if it works :-)

Johan

From: Girish Gopinath
Date: Wednesday, 10 May 2017 at 15:08
To: pjsip list, Johan Lantz
Subject: Re: [pjsip] NAT64 ios issue

Updated content length needs more bytes than old one, we must do expand
________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Girish Gopinath
2017-05-10 14:16:15 UTC
Permalink
Hi Johan:


Thank you for the reply. Added logs below from an attempt to switch from audio call to video. The content length is never more than 1000, but in the logs it says 1253. Looks like I'm missing something here.


Thank you,


Girish


15:20:08.575 pjsua_core.c ....TX 1398 bytes Request msg INVITE/cseq=11944 (tdta0x12284d200) to TCP 2001:2:0:1baa::4225:2ca6:5060:
INVITE sip:mod_sofia@[2001:2:0:1baa::4225:2ca6]:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
Max-Forwards: 70
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Contact: <sip:104@[2001:2::aab1:292f:d2ac:6e72:35f5]:58184;transport=TCP;ob>
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
User-Agent: VoIPUA-1.0 iOS-10.3.1/arm-iPhone8,1/iOS-SDK
Content-Type: application/sdp
Content-Length: 668

v=0
o=- 3703398596 3703398599 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
s=pjmedia
b=AS:352
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 0 99 9 96
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:64000
a=rtcp:4001 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:99 speex/32000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
m=video 4004 RTP/AVP 97
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:256000
a=rtcp:4005 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--
15:20:08.781 pj_nat64.c !.ipv6_mod_on_rx
15:20:08.781 pj_nat64.c .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.781 pj_nat64.c .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.781 pj_nat64.c .SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

15:20:08.781 pj_nat64.c .***************************************************************
15:20:08.781 pj_nat64.c .Scanner syntax error at
15:20:08.781 pj_nat64.c .Error: Parsing of the incoming INVITE/200 OK failed at . Leave incoming buffer as is
15:20:08.781 pjsua_core.c .RX 375 bytes Response msg 100/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

--end msg--
15:20:08.789 pj_nat64.c .ipv6_mod_on_rx
15:20:08.789 pj_nat64.c .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.789 pj_nat64.c .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.789 pj_nat64.c .SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP4 XX.XX.44.166
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

15:20:08.789 pj_nat64.c .***************************************************************
15:20:08.789 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.793 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.794 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.795 pj_nat64.c .Scanner syntax error at
15:20:08.795 pj_nat64.c .Current Content-Length is: 358 and new Content-Length is 1253 .
15:20:08.795 pj_nat64.c .Updated content length needs more bytes than old one, we must do expand and copy. TODO
15:20:08.795 pj_nat64.c .We have successfully parsed the INVITE/200 OK until EOF. Replace rx buffer. pjsip will now print the modified rx packet.
15:20:08.795 pj_nat64.c .Host in Contact header is XX.XX.44.166
15:20:08.796 pjsua_core.c .RX 1914 bytes Response msg 200/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP6 2001:2:0:1baa::4225:2ca6
s=FreeSWITCH
c=IN IP6 2001:2:0:1baa::4225:2ca6
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP6 2001:2:0:1baa::4225:2ca6
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--

15:20:08.797 sdp.c ....Error parsing SDP in line 15 col 0: Success
Assertion failed: (ctx.last_error != PJ_SUCCESS), function pjmedia_sdp_parse, file ../src/pjmedia/sdp.c, line 1349.
(lldb)



________________________________
From: JOHAN LANTZ <***@telefonica.com>
Sent: Wednesday, May 10, 2017 7:00 PM
To: Girish Gopinath; pjsip list
Subject: Re: [pjsip] NAT64 ios issue

Could you send an example of the sdp you are processing?

I assume this simply means that previously your content length used for instance 3 chars, something like 980 and then after the manipulation content length is more than 1000 bytes meaning we need 4 characters instead of 3. IIRC my sdpŽs were quite far away from the limit so I added that scenario as a corner case that I did not implement. I think you will be able to fix it yourself if you spend some time on it. I am going to spend a little time on this code this week but I can not promise I have time to add this scenario so I suggest you start by trying to fix it yourself (and contribute the fix back to GitHub if it works :-)

Johan

From: Girish Gopinath
Date: Wednesday, 10 May 2017 at 15:08
To: pjsip list, Johan Lantz
Subject: Re: [pjsip] NAT64 ios issue

Updated content length needs more bytes than old one, we must do expand
________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Girish Gopinath
2017-05-12 11:41:29 UTC
Permalink
Hi Johan:


This has been resolved. The problem was due to our FreeSwitch server sending INFO messages to the client every time it tries for a session update (audio to video and vice versa). We added some logs to see what was causing the content length to go beyond 1000 bytes, and were surprised to see the buffer being passed as an argument to calculate_new_content_length function. Here it is:


v=0
o=FreeSWITCH 1494550159 1494550161 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 32392 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:32393 IN IP4 XX.XX.44.166
m=video 30442 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
INFO sip:104@[2001:2::aab1:f863:a967:5bab:f24]:62007;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP XX.XX.44.166;branch=z9hG4bKDFgHZDr6Kpvep
Max-Forwards: 70
From: <sip:***@devpbx.pbxonline.com>;tag=SQ8ervgXBXrXF
To: <sip:***@devpbx.pbxonline.com>;tag=cqaxfyCBeIKml95wpBVFbzZkWTQ0QuFB
Call-ID: mTLalvJyCpgsLz-AbJcwMx3JxcKuKh8m
CSeq: 106955541 INFO
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: VoIP-PBX
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/media_control+xml
Content-Length: 175

<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<vc_primitive>
<to_encoder>
<picture_fast_update>
</picture_fast_update>
</to_encoder>
</vc_primitive>
</media_control>

We modified the function to get exact length of SDP body. I don't know if this is a problem others would experience and not sure you want to patch your code. Anyways, attaching the patch file.


48a49
> int len;
50a52,53
> char* body_end;
>
52a56,60
> body_end = strstr(body_start,"INFO sip");
> if(body_end != NULL) {
> len = body_end - body_start;
> return len;
> }



Regards,

Girish

________________________________
From: pjsip <pjsip-***@lists.pjsip.org> on behalf of Girish Gopinath <***@hotmail.com>
Sent: Wednesday, May 10, 2017 7:46 PM
To: JOHAN LANTZ; pjsip list
Subject: Re: [pjsip] NAT64 ios issue


Hi Johan:


Thank you for the reply. Added logs below from an attempt to switch from audio call to video. The content length is never more than 1000, but in the logs it says 1253. Looks like I'm missing something here.


Thank you,


Girish


15:20:08.575 pjsua_core.c ....TX 1398 bytes Request msg INVITE/cseq=11944 (tdta0x12284d200) to TCP 2001:2:0:1baa::4225:2ca6:5060:
INVITE sip:mod_sofia@[2001:2:0:1baa::4225:2ca6]:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
Max-Forwards: 70
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Contact: <sip:104@[2001:2::aab1:292f:d2ac:6e72:35f5]:58184;transport=TCP;ob>
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
User-Agent: VoIPUA-1.0 iOS-10.3.1/arm-iPhone8,1/iOS-SDK
Content-Type: application/sdp
Content-Length: 668

v=0
o=- 3703398596 3703398599 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
s=pjmedia
b=AS:352
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 0 99 9 96
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:64000
a=rtcp:4001 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:99 speex/32000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
m=video 4004 RTP/AVP 97
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:256000
a=rtcp:4005 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--
15:20:08.781 pj_nat64.c !.ipv6_mod_on_rx
15:20:08.781 pj_nat64.c .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.781 pj_nat64.c .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.781 pj_nat64.c .SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

15:20:08.781 pj_nat64.c .***************************************************************
15:20:08.781 pj_nat64.c .Scanner syntax error at
15:20:08.781 pj_nat64.c .Error: Parsing of the incoming INVITE/200 OK failed at . Leave incoming buffer as is
15:20:08.781 pjsua_core.c .RX 375 bytes Response msg 100/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

--end msg--
15:20:08.789 pj_nat64.c .ipv6_mod_on_rx
15:20:08.789 pj_nat64.c .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.789 pj_nat64.c .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.789 pj_nat64.c .SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP4 XX.XX.44.166
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

15:20:08.789 pj_nat64.c .***************************************************************
15:20:08.789 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.793 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.794 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.795 pj_nat64.c .Scanner syntax error at
15:20:08.795 pj_nat64.c .Current Content-Length is: 358 and new Content-Length is 1253 .
15:20:08.795 pj_nat64.c .Updated content length needs more bytes than old one, we must do expand and copy. TODO
15:20:08.795 pj_nat64.c .We have successfully parsed the INVITE/200 OK until EOF. Replace rx buffer. pjsip will now print the modified rx packet.
15:20:08.795 pj_nat64.c .Host in Contact header is XX.XX.44.166
15:20:08.796 pjsua_core.c .RX 1914 bytes Response msg 200/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP6 2001:2:0:1baa::4225:2ca6
s=FreeSWITCH
c=IN IP6 2001:2:0:1baa::4225:2ca6
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP6 2001:2:0:1baa::4225:2ca6
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--

15:20:08.797 sdp.c ....Error parsing SDP in line 15 col 0: Success
Assertion failed: (ctx.last_error != PJ_SUCCESS), function pjmedia_sdp_parse, file ../src/pjmedia/sdp.c, line 1349.
(lldb)



________________________________
From: JOHAN LANTZ <***@telefonica.com>
Sent: Wednesday, May 10, 2017 7:00 PM
To: Girish Gopinath; pjsip list
Subject: Re: [pjsip] NAT64 ios issue

Could you send an example of the sdp you are processing?

I assume this simply means that previously your content length used for instance 3 chars, something like 980 and then after the manipulation content length is more than 1000 bytes meaning we need 4 characters instead of 3. IIRC my sdpŽs were quite far away from the limit so I added that scenario as a corner case that I did not implement. I think you will be able to fix it yourself if you spend some time on it. I am going to spend a little time on this code this week but I can not promise I have time to add this scenario so I suggest you start by trying to fix it yourself (and contribute the fix back to GitHub if it works :-)

Johan

From: Girish Gopinath
Date: Wednesday, 10 May 2017 at 15:08
To: pjsip list, Johan Lantz
Subject: Re: [pjsip] NAT64 ios issue

Updated content length needs more bytes than old one, we must do expand
________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
JOHAN LANTZ
2017-05-13 07:29:15 UTC
Permalink
Hi Girish


Happy you solved it. However proceed with caution since the INFO message is not in the sdp, it's a new message that appears to be appended directly after the INVITE message.


So while it is possible that the code could benefit from a better check to get the end of the message if the buffer contains multiple messages but to explicitly search for SIP INFO is not the solution and it might break if you modify the config of your FS later.


Best Regards


Johan


________________________________
From: Girish Gopinath <***@hotmail.com>
Sent: Friday, May 12, 2017 1:41 PM
To: JOHAN LANTZ; pjsip list
Subject: Re: [pjsip] NAT64 ios issue


Hi Johan:


This has been resolved. The problem was due to our FreeSwitch server sending INFO messages to the client every time it tries for a session update (audio to video and vice versa). We added some logs to see what was causing the content length to go beyond 1000 bytes, and were surprised to see the buffer being passed as an argument to calculate_new_content_length function. Here it is:


v=0
o=FreeSWITCH 1494550159 1494550161 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 32392 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:32393 IN IP4 XX.XX.44.166
m=video 30442 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
INFO sip:104@[2001:2::aab1:f863:a967:5bab:f24]:62007;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP XX.XX.44.166;branch=z9hG4bKDFgHZDr6Kpvep
Max-Forwards: 70
From: <sip:***@devpbx.pbxonline.com>;tag=SQ8ervgXBXrXF
To: <sip:***@devpbx.pbxonline.com>;tag=cqaxfyCBeIKml95wpBVFbzZkWTQ0QuFB
Call-ID: mTLalvJyCpgsLz-AbJcwMx3JxcKuKh8m
CSeq: 106955541 INFO
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: VoIP-PBX
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/media_control+xml
Content-Length: 175

<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<vc_primitive>
<to_encoder>
<picture_fast_update>
</picture_fast_update>
</to_encoder>
</vc_primitive>
</media_control>

We modified the function to get exact length of SDP body. I don't know if this is a problem others would experience and not sure you want to patch your code. Anyways, attaching the patch file.


48a49
> int len;
50a52,53
> char* body_end;
>
52a56,60
> body_end = strstr(body_start,"INFO sip");
> if(body_end != NULL) {
> len = body_end - body_start;
> return len;
> }



Regards,

Girish

________________________________
From: pjsip <pjsip-***@lists.pjsip.org> on behalf of Girish Gopinath <***@hotmail.com>
Sent: Wednesday, May 10, 2017 7:46 PM
To: JOHAN LANTZ; pjsip list
Subject: Re: [pjsip] NAT64 ios issue


Hi Johan:


Thank you for the reply. Added logs below from an attempt to switch from audio call to video. The content length is never more than 1000, but in the logs it says 1253. Looks like I'm missing something here.


Thank you,


Girish


15:20:08.575 pjsua_core.c ....TX 1398 bytes Request msg INVITE/cseq=11944 (tdta0x12284d200) to TCP 2001:2:0:1baa::4225:2ca6:5060:
INVITE sip:mod_sofia@[2001:2:0:1baa::4225:2ca6]:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
Max-Forwards: 70
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Contact: <sip:104@[2001:2::aab1:292f:d2ac:6e72:35f5]:58184;transport=TCP;ob>
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
User-Agent: VoIPUA-1.0 iOS-10.3.1/arm-iPhone8,1/iOS-SDK
Content-Type: application/sdp
Content-Length: 668

v=0
o=- 3703398596 3703398599 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
s=pjmedia
b=AS:352
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 0 99 9 96
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:64000
a=rtcp:4001 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:99 speex/32000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
m=video 4004 RTP/AVP 97
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:256000
a=rtcp:4005 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--
15:20:08.781 pj_nat64.c !.ipv6_mod_on_rx
15:20:08.781 pj_nat64.c .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.781 pj_nat64.c .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.781 pj_nat64.c .SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

15:20:08.781 pj_nat64.c .***************************************************************
15:20:08.781 pj_nat64.c .Scanner syntax error at
15:20:08.781 pj_nat64.c .Error: Parsing of the incoming INVITE/200 OK failed at . Leave incoming buffer as is
15:20:08.781 pjsua_core.c .RX 375 bytes Response msg 100/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

--end msg--
15:20:08.789 pj_nat64.c .ipv6_mod_on_rx
15:20:08.789 pj_nat64.c .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.789 pj_nat64.c .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.789 pj_nat64.c .SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP4 XX.XX.44.166
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

15:20:08.789 pj_nat64.c .***************************************************************
15:20:08.789 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.793 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.794 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.795 pj_nat64.c .Scanner syntax error at
15:20:08.795 pj_nat64.c .Current Content-Length is: 358 and new Content-Length is 1253 .
15:20:08.795 pj_nat64.c .Updated content length needs more bytes than old one, we must do expand and copy. TODO
15:20:08.795 pj_nat64.c .We have successfully parsed the INVITE/200 OK until EOF. Replace rx buffer. pjsip will now print the modified rx packet.
15:20:08.795 pj_nat64.c .Host in Contact header is XX.XX.44.166
15:20:08.796 pjsua_core.c .RX 1914 bytes Response msg 200/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP6 2001:2:0:1baa::4225:2ca6
s=FreeSWITCH
c=IN IP6 2001:2:0:1baa::4225:2ca6
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP6 2001:2:0:1baa::4225:2ca6
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--

15:20:08.797 sdp.c ....Error parsing SDP in line 15 col 0: Success
Assertion failed: (ctx.last_error != PJ_SUCCESS), function pjmedia_sdp_parse, file ../src/pjmedia/sdp.c, line 1349.
(lldb)



________________________________
From: JOHAN LANTZ <***@telefonica.com>
Sent: Wednesday, May 10, 2017 7:00 PM
To: Girish Gopinath; pjsip list
Subject: Re: [pjsip] NAT64 ios issue

Could you send an example of the sdp you are processing?

I assume this simply means that previously your content length used for instance 3 chars, something like 980 and then after the manipulation content length is more than 1000 bytes meaning we need 4 characters instead of 3. IIRC my sdpŽs were quite far away from the limit so I added that scenario as a corner case that I did not implement. I think you will be able to fix it yourself if you spend some time on it. I am going to spend a little time on this code this week but I can not promise I have time to add this scenario so I suggest you start by trying to fix it yourself (and contribute the fix back to GitHub if it works :-)

Johan

From: Girish Gopinath
Date: Wednesday, 10 May 2017 at 15:08
To: pjsip list, Johan Lantz
Subject: Re: [pjsip] NAT64 ios issue

Updated content length needs more bytes than old one, we must do expand
________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Girish Gopinath
2017-05-15 07:06:19 UTC
Permalink
Hi Johan:


Thanks. Yes, I'm aware of it. It was a quick fix to resolve the issue. We will definitely change that later to pass the buffer with only the required message for calculating length.


Best Regards,


Girish

________________________________
From: JOHAN LANTZ <***@telefonica.com>
Sent: Saturday, May 13, 2017 12:59 PM
To: Girish Gopinath; pjsip list
Subject: Re: [pjsip] NAT64 ios issue


Hi Girish


Happy you solved it. However proceed with caution since the INFO message is not in the sdp, it's a new message that appears to be appended directly after the INVITE message.


So while it is possible that the code could benefit from a better check to get the end of the message if the buffer contains multiple messages but to explicitly search for SIP INFO is not the solution and it might break if you modify the config of your FS later.


Best Regards


Johan


________________________________
From: Girish Gopinath <***@hotmail.com>
Sent: Friday, May 12, 2017 1:41 PM
To: JOHAN LANTZ; pjsip list
Subject: Re: [pjsip] NAT64 ios issue


Hi Johan:


This has been resolved. The problem was due to our FreeSwitch server sending INFO messages to the client every time it tries for a session update (audio to video and vice versa). We added some logs to see what was causing the content length to go beyond 1000 bytes, and were surprised to see the buffer being passed as an argument to calculate_new_content_length function. Here it is:


v=0
o=FreeSWITCH 1494550159 1494550161 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 32392 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:32393 IN IP4 XX.XX.44.166
m=video 30442 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1
INFO sip:104@[2001:2::aab1:f863:a967:5bab:f24]:62007;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP XX.XX.44.166;branch=z9hG4bKDFgHZDr6Kpvep
Max-Forwards: 70
From: <sip:***@devpbx.pbxonline.com>;tag=SQ8ervgXBXrXF
To: <sip:***@devpbx.pbxonline.com>;tag=cqaxfyCBeIKml95wpBVFbzZkWTQ0QuFB
Call-ID: mTLalvJyCpgsLz-AbJcwMx3JxcKuKh8m
CSeq: 106955541 INFO
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: VoIP-PBX
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/media_control+xml
Content-Length: 175

<?xml version="1.0" encoding="utf-8" ?>
<media_control>
<vc_primitive>
<to_encoder>
<picture_fast_update>
</picture_fast_update>
</to_encoder>
</vc_primitive>
</media_control>

We modified the function to get exact length of SDP body. I don't know if this is a problem others would experience and not sure you want to patch your code. Anyways, attaching the patch file.


48a49
> int len;
50a52,53
> char* body_end;
>
52a56,60
> body_end = strstr(body_start,"INFO sip");
> if(body_end != NULL) {
> len = body_end - body_start;
> return len;
> }



Regards,

Girish

________________________________
From: pjsip <pjsip-***@lists.pjsip.org> on behalf of Girish Gopinath <***@hotmail.com>
Sent: Wednesday, May 10, 2017 7:46 PM
To: JOHAN LANTZ; pjsip list
Subject: Re: [pjsip] NAT64 ios issue


Hi Johan:


Thank you for the reply. Added logs below from an attempt to switch from audio call to video. The content length is never more than 1000, but in the logs it says 1253. Looks like I'm missing something here.


Thank you,


Girish


15:20:08.575 pjsua_core.c ....TX 1398 bytes Request msg INVITE/cseq=11944 (tdta0x12284d200) to TCP 2001:2:0:1baa::4225:2ca6:5060:
INVITE sip:mod_sofia@[2001:2:0:1baa::4225:2ca6]:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
Max-Forwards: 70
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Contact: <sip:104@[2001:2::aab1:292f:d2ac:6e72:35f5]:58184;transport=TCP;ob>
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, norefersub
User-Agent: VoIPUA-1.0 iOS-10.3.1/arm-iPhone8,1/iOS-SDK
Content-Type: application/sdp
Content-Length: 668

v=0
o=- 3703398596 3703398599 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
s=pjmedia
b=AS:352
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 98 97 0 99 9 96
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:64000
a=rtcp:4001 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:99 speex/32000
a=rtpmap:9 G722/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
m=video 4004 RTP/AVP 97
c=IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
b=TIAS:256000
a=rtcp:4005 IN IP6 2001:2::aab1:292f:d2ac:6e72:35f5
a=sendrecv
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--
15:20:08.781 pj_nat64.c !.ipv6_mod_on_rx
15:20:08.781 pj_nat64.c .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.781 pj_nat64.c .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.781 pj_nat64.c .SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

15:20:08.781 pj_nat64.c .***************************************************************
15:20:08.781 pj_nat64.c .Scanner syntax error at
15:20:08.781 pj_nat64.c .Error: Parsing of the incoming INVITE/200 OK failed at . Leave incoming buffer as is
15:20:08.781 pjsua_core.c .RX 375 bytes Response msg 100/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
User-Agent: Fusion-PBX
Content-Length: 0

--end msg--
15:20:08.789 pj_nat64.c .ipv6_mod_on_rx
15:20:08.789 pj_nat64.c .Incoming INVITE or 200 OK. If they contain IPv4 addresses, we need to change to ipv6
15:20:08.789 pj_nat64.c .**********Incoming INVITE or 200 with IPv4 address*************
15:20:08.789 pj_nat64.c .SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP4 XX.XX.44.166
s=FreeSWITCH
c=IN IP4 XX.XX.44.166
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP4 XX.XX.44.166
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

15:20:08.789 pj_nat64.c .***************************************************************
15:20:08.789 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.793 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.794 pj_nat64.c .Extracted ip4 address as XX.XX.44.166
15:20:08.795 pj_nat64.c .Scanner syntax error at
15:20:08.795 pj_nat64.c .Current Content-Length is: 358 and new Content-Length is 1253 .
15:20:08.795 pj_nat64.c .Updated content length needs more bytes than old one, we must do expand and copy. TODO
15:20:08.795 pj_nat64.c .We have successfully parsed the INVITE/200 OK until EOF. Replace rx buffer. pjsip will now print the modified rx packet.
15:20:08.795 pj_nat64.c .Host in Contact header is XX.XX.44.166
15:20:08.796 pjsua_core.c .RX 1914 bytes Response msg 200/INVITE/cseq=11944 (rdata0x122890f30) from TCP 2001:2:0:1baa::4225:2ca6:5060:
SIP/2.0 200 OK
Via: SIP/2.0/TCP XX.XX.117.54:47919;rport=47919;branch=z9hG4bKPjhfiX5T7SMfffGsyd8n6wdmhaKL2Yk263;alias
From: <sip:***@XX.XX.117.54;ob>;tag=YuPVVYlB3CRimhCfi-R9-rriu8ba5MbB
To: "SipApp100" <sip:***@devpbx.pbxonline.com>;tag=5Zv34Z5NQ22QF
Call-ID: ca1ba4ba-b008-1235-8fb0-00163e70e05f
CSeq: 11944 INVITE
Contact: <sip:***@XX.XX.44.166:5060;transport=tcp>
User-Agent: Fusion-PBX
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 358

v=0
o=FreeSWITCH 1494392300 1494392302 IN IP6 2001:2:0:1baa::4225:2ca6
s=FreeSWITCH
c=IN IP6 2001:2:0:1baa::4225:2ca6
t=0 0
m=audio 16812 RTP/AVP 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=ptime:20
a=rtcp:16813 IN IP6 2001:2:0:1baa::4225:2ca6
m=video 23982 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=42e01e; packetization-mode=1

--end msg--

15:20:08.797 sdp.c ....Error parsing SDP in line 15 col 0: Success
Assertion failed: (ctx.last_error != PJ_SUCCESS), function pjmedia_sdp_parse, file ../src/pjmedia/sdp.c, line 1349.
(lldb)



________________________________
From: JOHAN LANTZ <***@telefonica.com>
Sent: Wednesday, May 10, 2017 7:00 PM
To: Girish Gopinath; pjsip list
Subject: Re: [pjsip] NAT64 ios issue

Could you send an example of the sdp you are processing?

I assume this simply means that previously your content length used for instance 3 chars, something like 980 and then after the manipulation content length is more than 1000 bytes meaning we need 4 characters instead of 3. IIRC my sdpŽs were quite far away from the limit so I added that scenario as a corner case that I did not implement. I think you will be able to fix it yourself if you spend some time on it. I am going to spend a little time on this code this week but I can not promise I have time to add this scenario so I suggest you start by trying to fix it yourself (and contribute the fix back to GitHub if it works :-)

Johan

From: Girish Gopinath
Date: Wednesday, 10 May 2017 at 15:08
To: pjsip list, Johan Lantz
Subject: Re: [pjsip] NAT64 ios issue

Updated content length needs more bytes than old one, we must do expand
________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
Ashok Narvaneni
2017-04-05 13:23:46 UTC
Permalink
Thanks for the reply Johan.

Yes we tested the presence feature. Status messages from other clients
reaching the device. Even for the register we got the 200 ok from server
But No incoming calls.

Thanks,
Ashok Narvaneni.

On Wed, Apr 5, 2017 at 6:19 PM, JOHAN LANTZ <***@telefonica.com>
wrote:

> For this problem I really do not know. I think our system does not pay
> that much attention to the Contact header but simply connects the
> registered device with the TCP/TLS socket used.
>
> I doubt there is anything missing on the client side if you simply does
> not receive the INVITE. Are other packets reaching the device? MESSAGE,
> keep-alive, etc?
>
> Johan
>
> From: pjsip on behalf of Ashok Narvaneni
> Reply-To: pjsip list
> Date: Wednesday, 5 April 2017 at 14:40
>
> To: pjsip list
> Subject: Re: [pjsip] NAT64 ios issue
>
> Thank you very much Colin and Johan for your help.
>
> We have made some good progress. Below is the current status.
> IPV4 - Phone register successfully, both Incoming and outgoing calls are
> working fine.
> IPV6 - Phone register successfully, outgoing calls are working fine but
> when some one dial the extension of the phone under IPV6, FreeSwitch server
> doesn't send the INVITE to the phone .
>
> Below is the register packet received on the server. Is there any other
> change we need to make on the app or Is that a FreeSwitch issue. Contact
> header have IPV6 address.
>
> REGISTER sip:xxxxxx.xxx;transport=TCP SIP/2.0
> Via: SIP/2.0/TCP [2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;rport;branch=
> z9hG4bKPjq-wL2PpL4k0klpjECGxQ7duSoDQPzA6-;alias
> Max-Forwards: 70
> From: <sip:***@xxxxxx.xxx>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
> To: <sip:***@xxxxxx.xxx>
> Call-ID: rQmIvhvfa8krjErV-bKQTnDcsfK79INU
> CSeq: 57007 REGISTER
> User-Agent: SIPUA-1.0 iOS-10.0.1/arm-iPhone8,1/iOS-SDK
> Supported: outbound, path
> Contact: <sip:103@[2001:2::aab1:dc80:49bb:fedc:3c1b]:63025;
> transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:
> 00000000-0000-0000-0000-0000fea119f6>"
> Expires: 60
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
> REFER, MESSAGE, OPTIONS
> Content-Length: 0
>
> Thanks,
> Ashok Narvaneni.
>
> On Tue, Apr 4, 2017 at 8:15 PM, JOHAN LANTZ <***@telefonica.com>
> wrote:
>
>> Hi Ashok
>>
>> Glad the module is more or less doing the job for you. As you can see in
>> the README.md file on GitHub under bullet 2, there is an example on how you
>> can activate this only when connecting to a IPv6 network. Then IPv4
>> continues to work as it has always done. Just hook it into the
>> on_registration callback from pjsip and I think you will be fine.
>>
>> Johan
>>
>> From: pjsip on behalf of Ashok Narvaneni
>> Reply-To: pjsip list
>> Date: Tuesday, 4 April 2017 at 16:36
>> To: pjsip list
>> Subject: Re: [pjsip] NAT64 ios issue
>>
>> Hi Colin,
>>
>> Thanks again for your kind reply.
>> We will make the changes and post our findings.
>> Unfortunately this server is provided by our client which does't have ICE
>> support.
>>
>> Thanks,
>> Ashok Narvaneni.
>>
>> On Tue, Apr 4, 2017 at 7:59 PM, Colin Morelli <***@gmail.com>
>> wrote:
>>
>>> Ahsok,
>>>
>>> This is one of the reasons I had written my own module (well, that and
>>> supporting ICE). The module I linked does not perform any checks about the
>>> current connection to the SIP server. Among other things, one of the
>>> additional things my modules does is only operate when connected to the
>>> signaling server via IPv6. This can be accomplished by a simple check in
>>> the on_rx and on_tx methods, before touching the SDP:
>>>
>>> (tdata->tp_info.transport->factory->type & PJSIP_TRANSPORT_IPV6)
>>> == PJSIP_TRANSPORT_IPV6
>>>
>>> With that check at the beginning of the module methods, it should simply
>>> ignore anything that happens on an IPv4 transport and leave the SDP
>>> in-tact.
>>>
>>> As for PJSIP supporting dual stack mode - there's really no sense in
>>> trying to do this when ICE is available. PJSIP's ICE implementation can and
>>> does support dual stack. If you can enable ICE on your server side as well,
>>> that should work for your use case.
>>>
>>> Best,
>>> Colin
>>>
>>> On Tue, Apr 4, 2017 at 10:23 AM, Ashok Narvaneni <
>>> ***@gmail.com> wrote:
>>>
>>>> Hi Colin,
>>>>
>>>> We integrated the module as you suggested and it is working fine.
>>>> However it breaks when we connect the device with an IPV4 network. We
>>>> understand that pjsip does't support dual stack mode. So what is the best
>>>> way to do make the App work with both IPV6 and IPV4 networks.
>>>> Please suggest...
>>>>
>>>> Thanks,
>>>> Ashok Narvaneni.
>>>>
>>>>
>>>> On Fri, Mar 31, 2017 at 8:14 PM, Ashok Narvaneni <
>>>> ***@gmail.com> wrote:
>>>>
>>>>> Hi Colin,
>>>>>
>>>>> Thank you very much for detailed answer, I will try that patch and
>>>>> post my findings.
>>>>>
>>>>> Thanks,
>>>>> Ashok.
>>>>>
>>>>> On Fri, Mar 31, 2017 at 8:08 PM, Colin Morelli <
>>>>> ***@gmail.com> wrote:
>>>>>
>>>>>> Ashok,
>>>>>>
>>>>>> What's almost certainly happening here is that the SDP returned from
>>>>>> your server contains only IPv4 media addresses. When PJSIP goes to compare
>>>>>> the SDP to local capabilities, it finds only IPv4 addresses for the remote
>>>>>> endpoint, but can't find any local IPv4 interfaces. As a result, it thinks
>>>>>> there's no way it can communicate with the remote server and fails.
>>>>>>
>>>>>> I have been able to fix this with two steps:
>>>>>>
>>>>>> 1) Enable ICE negotiation on both your media server and PJSIP
>>>>>> client. ICE is helpful here because it allows the two endpoints to
>>>>>> communicate multiple candidate media addresses. This step *may* be
>>>>>> optional, although I've never really tested without this.
>>>>>> 2) Write a PJSIP module that intercepts incoming/outgoing SDPs to
>>>>>> work around the NAT64 issue. There's an example of one of these on
>>>>>> github <https://github.com/johanlantz/pj-nat64>, and I've written my
>>>>>> own for my app (unfortunately can't share at this time). The general steps
>>>>>> that need to be followed here are:
>>>>>>
>>>>>> - Intercept on_tx and on_rx PJSIP events
>>>>>> - When sending an outgoing SDP, if signaling is connected over IPv6,
>>>>>> then add an IPv4 address to the ICE candidates in the SDP (this step is
>>>>>> optional, and depends on whether or not your server will explicitly reject
>>>>>> an SDP that only contains IPv6 addresses)
>>>>>> - When receiving an incoming SDP, if signaling is connected over
>>>>>> IPv6, then iterate the ICE candidates in the SDP, find all IPv4 addresses,
>>>>>> synthesize IPv6 addresses for them (by passing the IPv4 addresses to
>>>>>> pj_getaddrinfo, iOS will return a synthesized IPv6 address if connected to
>>>>>> a NAT64 network), and add the synthesized IPv6 addresses to the ICE
>>>>>> candidates list
>>>>>>
>>>>>> As long as this module is registered with a higher priority than the
>>>>>> PJSIP transports module, the SDP will be rewritten before pjmedia actually
>>>>>> parses the SDP. By the time it gets to the media stack, it will see your
>>>>>> synthesized IPv6 addresses, which it can support, and should be able to
>>>>>> establish a media connection.
>>>>>>
>>>>>> Couple of tips here: don't underestimate the nuances of this issue.
>>>>>> It's not necessarily a *hard *problem, but there are a lot of cases
>>>>>> to consider. Once you solve the first issue, you then have the issue of
>>>>>> what happens when the user changes networks during a call (i.e. their phone
>>>>>> switches wifi networks, or off of wifi entirely). Additionally, if you're
>>>>>> working on Android, you probably have this issue on Android as well, but
>>>>>> Google as far as I know does not test apps on a NAT64 network like Apple
>>>>>> does.
>>>>>>
>>>>>> Apologies I can't be more specific at this time but I hope this
>>>>>> points you in the right direction. I think it'd be great for PJSIP to
>>>>>> include this in the core. NAT64 networks are likely to become more
>>>>>> prevalent, and it would be considerably less work to simply add to the core
>>>>>> than it would be to maintain a separate module.
>>>>>>
>>>>>> Best,
>>>>>> Colin
>>>>>>
>>>>>> On Fri, Mar 31, 2017 at 10:14 AM, Ashok Narvaneni <
>>>>>> ***@gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> We are trying to connect to IPV4 server from our pjsip ios app with
>>>>>>> NAT64.
>>>>>>> We can able to register with the server successfully But when we
>>>>>>> make calls their is no audio and call disconnects.
>>>>>>> Below is the error.
>>>>>>>
>>>>>>> *19:39:43.256 pjsua_media.c .....Call 1: updating media..*
>>>>>>>
>>>>>>> *19:39:43.256 pjsua_media.c ......pjmedia_stream_info_from_sdp()
>>>>>>> failed for call_id 1 media 0: Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:0:
>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_media.c
>>>>>>> ......pjmedia_vid_stream_info_from_sdp() failed for call_id 1 media 1:
>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_media.c ......Error updating media call01:1:
>>>>>>> Unsupported address family (PJ_EAFNOTSUP)*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_call.c .....Unable to create media session:
>>>>>>> No active media stream after negotiation (PJMEDIA_SDPNEG_ENOMEDIA)
>>>>>>> [status=220048]*
>>>>>>>
>>>>>>> *19:39:43.257 pjsua_core.c ........TX 389 bytes Request msg
>>>>>>> CANCEL/cseq=17639 (tdta0x1021ce200) to TCP 2001:2:0:1baa::4225:2ca6:5060:*
>>>>>>>
>>>>>>> What could be wrong? Can someone please help me on this.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ashok Narvaneni.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>>
>>>>>>> pjsip mailing list
>>>>>>> ***@lists.pjsip.org
>>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Visit our blog: http://blog.pjsip.org
>>>>>>
>>>>>> pjsip mailing list
>>>>>> ***@lists.pjsip.org
>>>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Visit our blog: http://blog.pjsip.org
>>>>
>>>> pjsip mailing list
>>>> ***@lists.pjsip.org
>>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> ***@lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> ***@lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> ***@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
Loading...