Re: NAT64 ios issue

Ashok Narvaneni <ashoknarvaneni7@xxxxxxxxx> · Mon, 17 Apr 2017 16:49:34 +0530

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:104@xxxxxxxxxx;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX

To: sip:103@xxxxxxxxxx;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:104@xxxxxxxxxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX

To: <sip:103@xxxxxxxxxx>;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:104@xxxxxxxxxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX

To: <sip:103@xxxxxxxxxx>;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:104@xxxxxxxxxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX

To: <sip:103@xxxxxxxxxx>;tag=jZ4Be8mcX701c

Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-

CSeq: 11133 INVITE

Contact: <sip:103@xxxxxxxxxx: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:103@xxxxxxxxxx>;tag=jZ4Be8mcX701c

To: <sip:104@xxxxxxxxxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX

Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-

CSeq: 105875569 INFO

Contact: <sip:103@xxxxxxxxxx: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:104@xxxxxxxxxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX

To: <sip:103@xxxxxxxxxx>;tag=jZ4Be8mcX701c

Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-

CSeq: 11133 INVITE

Contact: <sip:103@xxxxxxxxxx: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:103@xxxxxxxxxx>;tag=jZ4Be8mcX701c

To: <sip:104@xxxxxxxxxx>;tag=ZWHln0afNSKHYDFrsHssUtNHKeEMw3aX

Call-ID: .e0yHRYAvJ2x6IzznoN2anHtTmDM8IP-

CSeq: 105875569 INFO

Contact: <sip:103@xxxxxxxxxx: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 <ashoknarvaneni7@xxxxxxxxx> 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 <ashoknarvaneni7@xxxxxxxxx> 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 <colin.morelli@xxxxxxxxx> 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 <johan.lantz@xxxxxxxxxxxxxx> 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:  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:103@xxxxxxxxxx>;tag=3oiEgXukA1tcpLpzuDPslVusej23ql5a
To: <sip:103@xxxxxxxxxx>
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 
<johan.lantz@xxxxxxxxxxxxxx> 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:  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 
<colin.morelli@xxxxxxxxx> 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 
<ashoknarvaneni7@xxxxxxxxx> 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 
<ashoknarvaneni7@xxxxxxxxx> 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 
<colin.morelli@xxxxxxxxx> 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, 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 <ashoknarvaneni7@xxxxxxxxx> 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

pjsip@xxxxxxxxxxxxxxx

http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________

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

pjsip mailing list

pjsip@xxxxxxxxxxxxxxx

http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________

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

pjsip mailing list

pjsip@xxxxxxxxxxxxxxx

http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________

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

pjsip mailing list

pjsip@xxxxxxxxxxxxxxx

http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________

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

pjsip mailing list

pjsip@xxxxxxxxxxxxxxx

http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________

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

pjsip mailing list

pjsip@xxxxxxxxxxxxxxx

http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________

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

pjsip mailing list

pjsip@xxxxxxxxxxxxxxx

http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

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

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org