OB
Olivier Beytrison
Mon, Oct 1, 2007 2:31 PM
Hello,
I'm very new to pjsip, I discovered it only this morning, but it might
be my life saviour.
I'm currently involved in a project about developing an IMS client for
the Next Generation Networks as defined by the 3GPP. This client will
run on PDA under Windows Mobile 5/6.
I'm very interested into pjsip because the WM5/6 SDK lacks a sip/sdp/rtp
stack.
Thus, I have a question :
Is it viable to use the pjsip libs in a C# for CF.NET using marshalling
? or should i really stick with C/C++ for embedded devices for my
application?
The object-oriented side of C# is really appealing and the easy way to
create the GUI as well. But off course it is not possible to directly
use pjsip in C#, that's why i'm thinking about making an intermediate
C++ code between the C# and the libs.
Thanks in advance for your answers
Regards,
Olivier B.
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Hello,
I'm very new to pjsip, I discovered it only this morning, but it might
be my life saviour.
I'm currently involved in a project about developing an IMS client for
the Next Generation Networks as defined by the 3GPP. This client will
run on PDA under Windows Mobile 5/6.
I'm very interested into pjsip because the WM5/6 SDK lacks a sip/sdp/rtp
stack.
Thus, I have a question :
Is it viable to use the pjsip libs in a C# for CF.NET using marshalling
? or should i really stick with C/C++ for embedded devices for my
application?
The object-oriented side of C# is really appealing and the easy way to
create the GUI as well. But off course it is not possible to directly
use pjsip in C#, that's why i'm thinking about making an intermediate
C++ code between the C# and the libs.
Thanks in advance for your answers
Regards,
Olivier B.
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
BP
Benny Prijono
Tue, Oct 2, 2007 6:21 AM
Hi Olivier,
welcome to the list!
Indeed when developing applications on Windows, you have two
choices, to develop in C++ directly using pjsip, or to develop it
with .NET by creating pjsip wrapper for .NET. Well actually there
are two more options for Windows, if we count Python and TCL. ;-)
Whether to use C++ or .NET would depend on how much time you'd
prepare to spend on creating pjsip .NET wrapper, vs how much more
productivity you'd gain by using .NET. The cost of creating the .NET
wrapper further depends on how many APIs would you need from pjsip.
FYI pjsua-lib has more than 100 APIs (please see [1]), it would be
time consuming to implement all of these in your wrapper. So I would
imagine that you would create yet another abstraction on top of
pjsua-lib, select the APIs that you need, and export these in your
wrapper, so that it has less APIs.
Alternatively you could also join Sasa Coh's project. She's created
.NET application on top of pjsip, and there is a .NET wrapper for
pjsip as part of this project. Please see [2]. Personally I prefer
this approach, not only it would help you get there faster, but it
would also help yet another open source project.
So all is possible, the choice is yours.
cheers,
-benny
[1] http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB.htm
[2] http://www.pjsip.org/trac/wiki/FAQ#activex
Olivier Beytrison wrote:
Hello,
I'm very new to pjsip, I discovered it only this morning, but it might
be my life saviour.
I'm currently involved in a project about developing an IMS client for
the Next Generation Networks as defined by the 3GPP. This client will
run on PDA under Windows Mobile 5/6.
I'm very interested into pjsip because the WM5/6 SDK lacks a sip/sdp/rtp
stack.
Thus, I have a question :
Is it viable to use the pjsip libs in a C# for CF.NET using marshalling
? or should i really stick with C/C++ for embedded devices for my
application?
The object-oriented side of C# is really appealing and the easy way to
create the GUI as well. But off course it is not possible to directly
use pjsip in C#, that's why i'm thinking about making an intermediate
C++ code between the C# and the libs.
Thanks in advance for your answers
Regards,
Olivier B.
Hi Olivier,
welcome to the list!
Indeed when developing applications on Windows, you have two
choices, to develop in C++ directly using pjsip, or to develop it
with .NET by creating pjsip wrapper for .NET. Well actually there
are two more options for Windows, if we count Python and TCL. ;-)
Whether to use C++ or .NET would depend on how much time you'd
prepare to spend on creating pjsip .NET wrapper, vs how much more
productivity you'd gain by using .NET. The cost of creating the .NET
wrapper further depends on how many APIs would you need from pjsip.
FYI pjsua-lib has more than 100 APIs (please see [1]), it would be
time consuming to implement all of these in your wrapper. So I would
imagine that you would create yet another abstraction on top of
pjsua-lib, select the APIs that you need, and export these in your
wrapper, so that it has less APIs.
Alternatively you could also join Sasa Coh's project. She's created
.NET application on top of pjsip, and there is a .NET wrapper for
pjsip as part of this project. Please see [2]. Personally I prefer
this approach, not only it would help you get there faster, but it
would also help yet another open source project.
So all is possible, the choice is yours.
cheers,
-benny
[1] http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB.htm
[2] http://www.pjsip.org/trac/wiki/FAQ#activex
Olivier Beytrison wrote:
> Hello,
>
> I'm very new to pjsip, I discovered it only this morning, but it might
> be my life saviour.
>
> I'm currently involved in a project about developing an IMS client for
> the Next Generation Networks as defined by the 3GPP. This client will
> run on PDA under Windows Mobile 5/6.
>
> I'm very interested into pjsip because the WM5/6 SDK lacks a sip/sdp/rtp
> stack.
>
> Thus, I have a question :
> Is it viable to use the pjsip libs in a C# for CF.NET using marshalling
> ? or should i really stick with C/C++ for embedded devices for my
> application?
>
> The object-oriented side of C# is really appealing and the easy way to
> create the GUI as well. But off course it is not possible to directly
> use pjsip in C#, that's why i'm thinking about making an intermediate
> C++ code between the C# and the libs.
>
> Thanks in advance for your answers
>
> Regards,
> Olivier B.
>
--
Benny Prijono
http://www.pjsip.org
OB
Olivier Beytrison
Tue, Oct 2, 2007 7:47 AM
Hello Benny,
Thank you very much for your welcome.
As for your answers, I've already contacted Sasa off-list and got also a
quick answer from her. There might be another possibility, the one to
use the client/server model. Having the core function built in C++ and
listening to the GUI (the client) on a local port might make it safer
and more flexible.
And don't forget that the target of this open-source application is a
mobile device running Windows Mobile 5 or 6, with its compact framework
.Net.
If we stay on the wrapper idea, we will indeed develop a sort of
"intermediate" API which will provide only what is strictly needed by
the GUI part of the application, this preventing us to wrap over 100
functions and callbacks.
Anyway, I'll keep the list informed on which way the project will take,
and will be happy to listen to anyone's suggestion or ideas :)
Regards,
Olivier B.
Benny Prijono a écrit :
Hi Olivier,
welcome to the list!
Indeed when developing applications on Windows, you have two
choices, to develop in C++ directly using pjsip, or to develop it
with .NET by creating pjsip wrapper for .NET. Well actually there
are two more options for Windows, if we count Python and TCL. ;-)
Whether to use C++ or .NET would depend on how much time you'd
prepare to spend on creating pjsip .NET wrapper, vs how much more
productivity you'd gain by using .NET. The cost of creating the .NET
wrapper further depends on how many APIs would you need from pjsip.
FYI pjsua-lib has more than 100 APIs (please see [1]), it would be
time consuming to implement all of these in your wrapper. So I would
imagine that you would create yet another abstraction on top of
pjsua-lib, select the APIs that you need, and export these in your
wrapper, so that it has less APIs.
Alternatively you could also join Sasa Coh's project. She's created
.NET application on top of pjsip, and there is a .NET wrapper for
pjsip as part of this project. Please see [2]. Personally I prefer
this approach, not only it would help you get there faster, but it
would also help yet another open source project.
So all is possible, the choice is yours.
cheers,
-benny
[1] http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB.htm
[2] http://www.pjsip.org/trac/wiki/FAQ#activex
Olivier Beytrison wrote:
Hello,
I'm very new to pjsip, I discovered it only this morning, but it might
be my life saviour.
I'm currently involved in a project about developing an IMS client for
the Next Generation Networks as defined by the 3GPP. This client will
run on PDA under Windows Mobile 5/6.
I'm very interested into pjsip because the WM5/6 SDK lacks a sip/sdp/rtp
stack.
Thus, I have a question :
Is it viable to use the pjsip libs in a C# for CF.NET using marshalling
? or should i really stick with C/C++ for embedded devices for my
application?
The object-oriented side of C# is really appealing and the easy way to
create the GUI as well. But off course it is not possible to directly
use pjsip in C#, that's why i'm thinking about making an intermediate
C++ code between the C# and the libs.
Thanks in advance for your answers
Regards,
Olivier B.
Hello Benny,
Thank you very much for your welcome.
As for your answers, I've already contacted Sasa off-list and got also a
quick answer from her. There might be another possibility, the one to
use the client/server model. Having the core function built in C++ and
listening to the GUI (the client) on a local port might make it safer
and more flexible.
And don't forget that the target of this open-source application is a
mobile device running Windows Mobile 5 or 6, with its compact framework
.Net.
If we stay on the wrapper idea, we will indeed develop a sort of
"intermediate" API which will provide only what is strictly needed by
the GUI part of the application, this preventing us to wrap over 100
functions and callbacks.
Anyway, I'll keep the list informed on which way the project will take,
and will be happy to listen to anyone's suggestion or ideas :)
Regards,
Olivier B.
Benny Prijono a écrit :
> Hi Olivier,
>
> welcome to the list!
>
> Indeed when developing applications on Windows, you have two
> choices, to develop in C++ directly using pjsip, or to develop it
> with .NET by creating pjsip wrapper for .NET. Well actually there
> are two more options for Windows, if we count Python and TCL. ;-)
>
> Whether to use C++ or .NET would depend on how much time you'd
> prepare to spend on creating pjsip .NET wrapper, vs how much more
> productivity you'd gain by using .NET. The cost of creating the .NET
> wrapper further depends on how many APIs would you need from pjsip.
> FYI pjsua-lib has more than 100 APIs (please see [1]), it would be
> time consuming to implement all of these in your wrapper. So I would
> imagine that you would create yet another abstraction on top of
> pjsua-lib, select the APIs that you need, and export these in your
> wrapper, so that it has less APIs.
>
> Alternatively you could also join Sasa Coh's project. She's created
> .NET application on top of pjsip, and there is a .NET wrapper for
> pjsip as part of this project. Please see [2]. Personally I prefer
> this approach, not only it would help you get there faster, but it
> would also help yet another open source project.
>
> So all is possible, the choice is yours.
>
> cheers,
> -benny
>
> [1] http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB.htm
> [2] http://www.pjsip.org/trac/wiki/FAQ#activex
>
>
> Olivier Beytrison wrote:
>> Hello,
>>
>> I'm very new to pjsip, I discovered it only this morning, but it might
>> be my life saviour.
>>
>> I'm currently involved in a project about developing an IMS client for
>> the Next Generation Networks as defined by the 3GPP. This client will
>> run on PDA under Windows Mobile 5/6.
>>
>> I'm very interested into pjsip because the WM5/6 SDK lacks a sip/sdp/rtp
>> stack.
>>
>> Thus, I have a question :
>> Is it viable to use the pjsip libs in a C# for CF.NET using marshalling
>> ? or should i really stick with C/C++ for embedded devices for my
>> application?
>>
>> The object-oriented side of C# is really appealing and the easy way to
>> create the GUI as well. But off course it is not possible to directly
>> use pjsip in C#, that's why i'm thinking about making an intermediate
>> C++ code between the C# and the libs.
>>
>> Thanks in advance for your answers
>>
>> Regards,
>> Olivier B.
>>
>
>
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
BP
Benny Prijono
Tue, Oct 2, 2007 8:04 AM
Hello Benny,
Thank you very much for your welcome.
As for your answers, I've already contacted Sasa off-list and got also a
quick answer from her. There might be another possibility, the one to
use the client/server model. Having the core function built in C++ and
listening to the GUI (the client) on a local port might make it safer
and more flexible.
Somehow I doubt this. If any, we're just reinventing ActiveX here!
And don't forget that the target of this open-source application is a
mobile device running Windows Mobile 5 or 6, with its compact framework
.Net.
Would that make any difference in the wrapper?
Another option is to build PJSUA-LIB as (unmanaged) DLL. We already
have the framework for exporting symbols in PJSIP (because it's
needed by Symbian S60, and that's what PJ_DECL()/PJ_DEF() are for!)
so creating a DLL might not be that hard. What I'm not sure is
whether it would be easy to access this DLL from .NET, considering
that data types (struct's) declarations are not exported by DLLs.
If we stay on the wrapper idea, we will indeed develop a sort of
"intermediate" API which will provide only what is strictly needed by
the GUI part of the application, this preventing us to wrap over 100
functions and callbacks.
The problem with that is of course different people will need
different APIs, so this might limit the reusability of the wrapper. ;-)
Comments anyone?
cheers,
-benny
Anyway, I'll keep the list informed on which way the project will take,
and will be happy to listen to anyone's suggestion or ideas :)
Regards,
Olivier B.
Olivier Beytrison wrote:
> Hello Benny,
>
> Thank you very much for your welcome.
>
> As for your answers, I've already contacted Sasa off-list and got also a
> quick answer from her. There might be another possibility, the one to
> use the client/server model. Having the core function built in C++ and
> listening to the GUI (the client) on a local port might make it safer
> and more flexible.
Somehow I doubt this. If any, we're just reinventing ActiveX here!
> And don't forget that the target of this open-source application is a
> mobile device running Windows Mobile 5 or 6, with its compact framework
> .Net.
Would that make any difference in the wrapper?
Another option is to build PJSUA-LIB as (unmanaged) DLL. We already
have the framework for exporting symbols in PJSIP (because it's
needed by Symbian S60, and that's what PJ_DECL()/PJ_DEF() are for!)
so creating a DLL might not be that hard. What I'm not sure is
whether it would be easy to access this DLL from .NET, considering
that data types (struct's) declarations are not exported by DLLs.
> If we stay on the wrapper idea, we will indeed develop a sort of
> "intermediate" API which will provide only what is strictly needed by
> the GUI part of the application, this preventing us to wrap over 100
> functions and callbacks.
The problem with that is of course different people will need
different APIs, so this might limit the reusability of the wrapper. ;-)
Comments anyone?
cheers,
-benny
> Anyway, I'll keep the list informed on which way the project will take,
> and will be happy to listen to anyone's suggestion or ideas :)
>
> Regards,
> Olivier B.
SC
Sasa Coh
Tue, Oct 2, 2007 8:14 AM
Hello!
Just as Olivier said, the simple client/server model (trivial RPC) could be
safer and more stable than current wrapper implementation. I'll do my best
to add example wrapper to sipek project asap.
btw: sasa == he && sasa != she // at least in my case :-)
Regards,
Sasa
On 10/2/07, Olivier Beytrison olivier@heliosnet.org wrote:
Hello Benny,
Thank you very much for your welcome.
As for your answers, I've already contacted Sasa off-list and got also a
quick answer from her. There might be another possibility, the one to
use the client/server model. Having the core function built in C++ and
listening to the GUI (the client) on a local port might make it safer
and more flexible.
And don't forget that the target of this open-source application is a
mobile device running Windows Mobile 5 or 6, with its compact framework
.Net.
If we stay on the wrapper idea, we will indeed develop a sort of
"intermediate" API which will provide only what is strictly needed by
the GUI part of the application, this preventing us to wrap over 100
functions and callbacks.
Anyway, I'll keep the list informed on which way the project will take,
and will be happy to listen to anyone's suggestion or ideas :)
Regards,
Olivier B.
Benny Prijono a écrit :
Hi Olivier,
welcome to the list!
Indeed when developing applications on Windows, you have two
choices, to develop in C++ directly using pjsip, or to develop it
with .NET by creating pjsip wrapper for .NET. Well actually there
are two more options for Windows, if we count Python and TCL. ;-)
Whether to use C++ or .NET would depend on how much time you'd
prepare to spend on creating pjsip .NET wrapper, vs how much more
productivity you'd gain by using .NET. The cost of creating the .NET
wrapper further depends on how many APIs would you need from pjsip.
FYI pjsua-lib has more than 100 APIs (please see [1]), it would be
time consuming to implement all of these in your wrapper. So I would
imagine that you would create yet another abstraction on top of
pjsua-lib, select the APIs that you need, and export these in your
wrapper, so that it has less APIs.
Alternatively you could also join Sasa Coh's project. She's created
.NET application on top of pjsip, and there is a .NET wrapper for
pjsip as part of this project. Please see [2]. Personally I prefer
this approach, not only it would help you get there faster, but it
would also help yet another open source project.
So all is possible, the choice is yours.
cheers,
-benny
[1] http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB.htm
[2] http://www.pjsip.org/trac/wiki/FAQ#activex
Olivier Beytrison wrote:
Hello,
I'm very new to pjsip, I discovered it only this morning, but it might
be my life saviour.
I'm currently involved in a project about developing an IMS client for
the Next Generation Networks as defined by the 3GPP. This client will
run on PDA under Windows Mobile 5/6.
I'm very interested into pjsip because the WM5/6 SDK lacks a
stack.
Thus, I have a question :
Is it viable to use the pjsip libs in a C# for CF.NET using marshalling
? or should i really stick with C/C++ for embedded devices for my
application?
The object-oriented side of C# is really appealing and the easy way to
create the GUI as well. But off course it is not possible to directly
use pjsip in C#, that's why i'm thinking about making an intermediate
C++ code between the C# and the libs.
Thanks in advance for your answers
Regards,
Olivier B.
Hello!
Just as Olivier said, the simple client/server model (trivial RPC) could be
safer and more stable than current wrapper implementation. I'll do my best
to add example wrapper to sipek project asap.
btw: sasa == he && sasa != she // at least in my case :-)
Regards,
Sasa
On 10/2/07, Olivier Beytrison <olivier@heliosnet.org> wrote:
>
> Hello Benny,
>
> Thank you very much for your welcome.
>
> As for your answers, I've already contacted Sasa off-list and got also a
> quick answer from her. There might be another possibility, the one to
> use the client/server model. Having the core function built in C++ and
> listening to the GUI (the client) on a local port might make it safer
> and more flexible.
>
> And don't forget that the target of this open-source application is a
> mobile device running Windows Mobile 5 or 6, with its compact framework
> .Net.
>
> If we stay on the wrapper idea, we will indeed develop a sort of
> "intermediate" API which will provide only what is strictly needed by
> the GUI part of the application, this preventing us to wrap over 100
> functions and callbacks.
>
> Anyway, I'll keep the list informed on which way the project will take,
> and will be happy to listen to anyone's suggestion or ideas :)
>
> Regards,
> Olivier B.
>
>
> Benny Prijono a écrit :
> > Hi Olivier,
> >
> > welcome to the list!
> >
> > Indeed when developing applications on Windows, you have two
> > choices, to develop in C++ directly using pjsip, or to develop it
> > with .NET by creating pjsip wrapper for .NET. Well actually there
> > are two more options for Windows, if we count Python and TCL. ;-)
> >
> > Whether to use C++ or .NET would depend on how much time you'd
> > prepare to spend on creating pjsip .NET wrapper, vs how much more
> > productivity you'd gain by using .NET. The cost of creating the .NET
> > wrapper further depends on how many APIs would you need from pjsip.
> > FYI pjsua-lib has more than 100 APIs (please see [1]), it would be
> > time consuming to implement all of these in your wrapper. So I would
> > imagine that you would create yet another abstraction on top of
> > pjsua-lib, select the APIs that you need, and export these in your
> > wrapper, so that it has less APIs.
> >
> > Alternatively you could also join Sasa Coh's project. She's created
> > .NET application on top of pjsip, and there is a .NET wrapper for
> > pjsip as part of this project. Please see [2]. Personally I prefer
> > this approach, not only it would help you get there faster, but it
> > would also help yet another open source project.
> >
> > So all is possible, the choice is yours.
> >
> > cheers,
> > -benny
> >
> > [1] http://www.pjsip.org/pjsip/docs/html/group__PJSUA__LIB.htm
> > [2] http://www.pjsip.org/trac/wiki/FAQ#activex
> >
> >
> > Olivier Beytrison wrote:
> >> Hello,
> >>
> >> I'm very new to pjsip, I discovered it only this morning, but it might
> >> be my life saviour.
> >>
> >> I'm currently involved in a project about developing an IMS client for
> >> the Next Generation Networks as defined by the 3GPP. This client will
> >> run on PDA under Windows Mobile 5/6.
> >>
> >> I'm very interested into pjsip because the WM5/6 SDK lacks a
> sip/sdp/rtp
> >> stack.
> >>
> >> Thus, I have a question :
> >> Is it viable to use the pjsip libs in a C# for CF.NET using marshalling
> >> ? or should i really stick with C/C++ for embedded devices for my
> >> application?
> >>
> >> The object-oriented side of C# is really appealing and the easy way to
> >> create the GUI as well. But off course it is not possible to directly
> >> use pjsip in C#, that's why i'm thinking about making an intermediate
> >> C++ code between the C# and the libs.
> >>
> >> Thanks in advance for your answers
> >>
> >> Regards,
> >> Olivier B.
> >>
> >
> >
>
> --
>
> Olivier Beytrison
> Telecommunication Engineer
> Mobile: +41 (0)78 619 73 53
> Mail: olivier@heliosnet.org
> GPG: 0x4FB83528 http://pgp.mit.edu/
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
OB
Olivier Beytrison
Tue, Oct 2, 2007 9:07 AM
If we stay on the wrapper idea, we will indeed develop a sort of
"intermediate" API which will provide only what is strictly needed by
the GUI part of the application, this preventing us to wrap over 100
functions and callbacks.
The problem with that is of course different people will need
different APIs, so this might limit the reusability of the wrapper. ;-)
Well, I have to consider a very short time-line. We need a first alpha
release of the client in one month, this giving us a very short time to
develop. I would love to develop a complete wrapper around the
pjsua-lib, but unfortunately I won't have the time to do it.
Another question comes to my mind, as we need to develop a 3GPP
compliant IMS/SIP client, we will need the re-INVITE SIP message, as
defined in the RFC 3261, allowing Mobility at the application layer (SIP
Session). Is it implemented in pjsip ?
Regards,
Olivier
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Benny Prijono a écrit :
> Olivier Beytrison wrote:
>> Hello Benny,
> [snip]
>
>> If we stay on the wrapper idea, we will indeed develop a sort of
>> "intermediate" API which will provide only what is strictly needed by
>> the GUI part of the application, this preventing us to wrap over 100
>> functions and callbacks.
>
> The problem with that is of course different people will need
> different APIs, so this might limit the reusability of the wrapper. ;-)
>
Well, I have to consider a very short time-line. We need a first alpha
release of the client in one month, this giving us a very short time to
develop. I would love to develop a complete wrapper around the
pjsua-lib, but unfortunately I won't have the time to do it.
Another question comes to my mind, as we need to develop a 3GPP
compliant IMS/SIP client, we will need the re-INVITE SIP message, as
defined in the RFC 3261, allowing Mobility at the application layer (SIP
Session). Is it implemented in pjsip ?
Regards,
Olivier
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
BP
Benny Prijono
Tue, Oct 2, 2007 10:06 AM
Another question comes to my mind, as we need to develop a 3GPP
compliant IMS/SIP client, we will need the re-INVITE SIP message, as
defined in the RFC 3261, allowing Mobility at the application layer (SIP
Session). Is it implemented in pjsip ?
I'm afraid I'm not familiar with IMS so I'm not sure what's missing,
if any, in pjsip to support that. Maybe others can comment.
cheers,
-benny
Olivier Beytrison wrote:
> Another question comes to my mind, as we need to develop a 3GPP
> compliant IMS/SIP client, we will need the re-INVITE SIP message, as
> defined in the RFC 3261, allowing Mobility at the application layer (SIP
> Session). Is it implemented in pjsip ?
I'm afraid I'm not familiar with IMS so I'm not sure what's missing,
if any, in pjsip to support that. Maybe others can comment.
cheers,
-benny
OB
Olivier Beytrison
Wed, Oct 10, 2007 12:49 PM
Hello,
Small update on my project.
So far, we successfully ported Sasa's Wrapper to WinCE. It worked almost
without any changes. Thanks a lot to him because his work is going to
save a lot of time for me :)
What currently works :
- Start pjsua
- registration
- set up a call
- receive a call
- hang up a call
- un-register
I still experience some issues :
- When calling pjsua_acc_del(accountID), the on_reg_state() callback
isn't called. Looking at the logs, pjsua delete the account before
receiving the 200 OK from the server, this preventing it from calling
the on_reg_state(pjsua_acc_id acc_id) callback, because the account
have already been deleted
- During a call, some times It doesn't send any sound. After putting on
hold the call, and retrieving it, the sounds works. And i get a lot
of BAD Ptr for the RTP session
- when calling pjsua_call_hangup(), it takes most of the time 8 to 15
seconds for the call to hang up. Same goes when the other UA initiate
the hang up
About the IMS-Specific things for SIP, it is mainly Headers. (like the
P-Access-Info header which describe which kind of "connection" the
signaling is sent on, like 3gpp-umts-cell, wireless-network, ect ect). I
can give you a small overview of the 3gpp-specific headers if you're
interested.
That's it for now, work is going on for the GUI, and hopefully we should
have a beta version in about 1 week.
Regards,
Olivier B.
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
Hello,
Small update on my project.
So far, we successfully ported Sasa's Wrapper to WinCE. It worked almost
without any changes. Thanks a lot to him because his work is going to
save a lot of time for me :)
What currently works :
- Start pjsua
- registration
- set up a call
- receive a call
- hang up a call
- un-register
I still experience some issues :
- When calling pjsua_acc_del(accountID), the on_reg_state() callback
isn't called. Looking at the logs, pjsua delete the account before
receiving the 200 OK from the server, this preventing it from calling
the on_reg_state(pjsua_acc_id acc_id) callback, because the account
have already been deleted
- During a call, some times It doesn't send any sound. After putting on
hold the call, and retrieving it, the sounds works. And i get a lot
of BAD Ptr for the RTP session
- when calling pjsua_call_hangup(), it takes most of the time 8 to 15
seconds for the call to hang up. Same goes when the other UA initiate
the hang up
About the IMS-Specific things for SIP, it is mainly Headers. (like the
P-Access-Info header which describe which kind of "connection" the
signaling is sent on, like 3gpp-umts-cell, wireless-network, ect ect). I
can give you a small overview of the 3gpp-specific headers if you're
interested.
That's it for now, work is going on for the GUI, and hopefully we should
have a beta version in about 1 week.
Regards,
Olivier B.
--
Olivier Beytrison
Telecommunication Engineer
Mobile: +41 (0)78 619 73 53
Mail: olivier@heliosnet.org
GPG: 0x4FB83528 http://pgp.mit.edu/
BP
Benny Prijono
Wed, Oct 10, 2007 4:51 PM
Hi Olivier,
Olivier Beytrison wrote:
I still experience some issues :
- When calling pjsua_acc_del(accountID), the on_reg_state() callback
isn't called. Looking at the logs, pjsua delete the account before
receiving the 200 OK from the server, this preventing it from calling
the on_reg_state(pjsua_acc_id acc_id) callback, because the account
have already been deleted
I think that's the expected behavior. From application's view, the
deletion happens immediately. Once the account is deleted, it is
gone as far as application is concerned, thus it will not hear any
more callbacks called on behalf of the account.
- During a call, some times It doesn't send any sound. After putting on
hold the call, and retrieving it, the sounds works. And i get a lot
of BAD Ptr for the RTP session
Not sure about this. Maybe you can get more information by following
the troubleshooting procedure from the sound problem Wiki
(http://www.pjsip.org/trac/wiki).
- when calling pjsua_call_hangup(), it takes most of the time 8 to 15
seconds for the call to hang up. Same goes when the other UA initiate
the hang up
This sounds like problem with Contact header calculation. Maybe the
IP address that is selected in Contact header is not the one that's
reachable from remote UA.
About the IMS-Specific things for SIP, it is mainly Headers. (like the
P-Access-Info header which describe which kind of "connection" the
signaling is sent on, like 3gpp-umts-cell, wireless-network, ect ect). I
can give you a small overview of the 3gpp-specific headers if you're
interested.
An IMS overview will be great! Not that I'm planning to implement
them (just yet), but any free info is always good. :)
cheers,
-benny
That's it for now, work is going on for the GUI, and hopefully we should
have a beta version in about 1 week.
Regards,
Olivier B.
Hi Olivier,
Olivier Beytrison wrote:
> I still experience some issues :
> - When calling pjsua_acc_del(accountID), the on_reg_state() callback
> isn't called. Looking at the logs, pjsua delete the account before
> receiving the 200 OK from the server, this preventing it from calling
> the on_reg_state(pjsua_acc_id acc_id) callback, because the account
> have already been deleted
I think that's the expected behavior. From application's view, the
deletion happens immediately. Once the account is deleted, it is
gone as far as application is concerned, thus it will not hear any
more callbacks called on behalf of the account.
> - During a call, some times It doesn't send any sound. After putting on
> hold the call, and retrieving it, the sounds works. And i get a lot
> of BAD Ptr for the RTP session
Not sure about this. Maybe you can get more information by following
the troubleshooting procedure from the sound problem Wiki
(http://www.pjsip.org/trac/wiki).
> - when calling pjsua_call_hangup(), it takes most of the time 8 to 15
> seconds for the call to hang up. Same goes when the other UA initiate
> the hang up
This sounds like problem with Contact header calculation. Maybe the
IP address that is selected in Contact header is not the one that's
reachable from remote UA.
> About the IMS-Specific things for SIP, it is mainly Headers. (like the
> P-Access-Info header which describe which kind of "connection" the
> signaling is sent on, like 3gpp-umts-cell, wireless-network, ect ect). I
> can give you a small overview of the 3gpp-specific headers if you're
> interested.
An IMS overview will be great! Not that I'm planning to implement
them (just yet), but any free info is always good. :)
cheers,
-benny
> That's it for now, work is going on for the GUI, and hopefully we should
> have a beta version in about 1 week.
>
> Regards,
>
> Olivier B.
>
--
Benny Prijono
http://www.pjsip.org
LH
Lafras Henning
Thu, Oct 11, 2007 5:48 AM
Hi Benny,Olivier
I had a similar problem.
It looks like PJSIP uses the Internet IP address(obtained from the STUN
server) in the contact header for calls relating to a registered account. If
you don't have a local LAN account with a contact override it also uses the
public IP address when receiving local LAN calls. I think some routers may
handle this with a loop back and some not.
The one UA actually remains in the calling state while the other is
confirmed.
Sound does go through but when the UA in calling state times out the call
will get disconnected.
It takes long to disconnect due to the fact that it retries 10 times (due to
wrong contact) and finally disconnects when it gives up.
Benny, it would be useful to be able to comment a config file with something
like -comment=
example config with local account override
--stun-srv=stun.fwdnet.net:3478
--comment=Following is the local lan account with a override - remove this
line in app.
--id=sip:10.0.0.10
--contact=sip:10.0.0.10
--next-account
--comment=Following is the local registered account - remove this line in
app.
--registrar=sip:fwd.pulver.com:5060
--id=sip:8664xx:xxxxxx@fwd.pulver.com
--proxy=sip:fwd.pulver.com:5060
--realm=fwd.pulver.com
--username=8664xx
--password=xxxxxx
regards
Lafras
----- Original Message -----
From: "Benny Prijono" bennylp@pjsip.org
To: "pjsip embedded/DSP SIP discussion" pjsip@lists.pjsip.org
Sent: Wednesday, October 10, 2007 6:51 PM
Subject: Re: [pjsip] pjsip for WM5/C#
Hi Olivier,
Olivier Beytrison wrote:
I still experience some issues :
- When calling pjsua_acc_del(accountID), the on_reg_state() callback
isn't called. Looking at the logs, pjsua delete the account before
receiving the 200 OK from the server, this preventing it from calling
the on_reg_state(pjsua_acc_id acc_id) callback, because the account
have already been deleted
I think that's the expected behavior. From application's view, the
deletion happens immediately. Once the account is deleted, it is
gone as far as application is concerned, thus it will not hear any
more callbacks called on behalf of the account.
- During a call, some times It doesn't send any sound. After putting on
hold the call, and retrieving it, the sounds works. And i get a lot
of BAD Ptr for the RTP session
Not sure about this. Maybe you can get more information by following
the troubleshooting procedure from the sound problem Wiki
(http://www.pjsip.org/trac/wiki).
- when calling pjsua_call_hangup(), it takes most of the time 8 to 15
seconds for the call to hang up. Same goes when the other UA initiate
the hang up
This sounds like problem with Contact header calculation. Maybe the
IP address that is selected in Contact header is not the one that's
reachable from remote UA.
About the IMS-Specific things for SIP, it is mainly Headers. (like the
P-Access-Info header which describe which kind of "connection" the
signaling is sent on, like 3gpp-umts-cell, wireless-network, ect ect). I
can give you a small overview of the 3gpp-specific headers if you're
interested.
An IMS overview will be great! Not that I'm planning to implement
them (just yet), but any free info is always good. :)
cheers,
-benny
That's it for now, work is going on for the GUI, and hopefully we should
have a beta version in about 1 week.
Regards,
Olivier B.
Hi Benny,Olivier
I had a similar problem.
It looks like PJSIP uses the Internet IP address(obtained from the STUN
server) in the contact header for calls relating to a registered account. If
you don't have a local LAN account with a contact override it also uses the
public IP address when receiving local LAN calls. I think some routers may
handle this with a loop back and some not.
The one UA actually remains in the calling state while the other is
confirmed.
Sound does go through but when the UA in calling state times out the call
will get disconnected.
It takes long to disconnect due to the fact that it retries 10 times (due to
wrong contact) and finally disconnects when it gives up.
Benny, it would be useful to be able to comment a config file with something
like -comment=
example config with local account override
--stun-srv=stun.fwdnet.net:3478
--comment=Following is the local lan account with a override - remove this
line in app.
--id=sip:10.0.0.10
--contact=sip:10.0.0.10
--next-account
--comment=Following is the local registered account - remove this line in
app.
--registrar=sip:fwd.pulver.com:5060
--id=sip:8664xx:xxxxxx@fwd.pulver.com
--proxy=sip:fwd.pulver.com:5060
--realm=fwd.pulver.com
--username=8664xx
--password=xxxxxx
regards
Lafras
----- Original Message -----
From: "Benny Prijono" <bennylp@pjsip.org>
To: "pjsip embedded/DSP SIP discussion" <pjsip@lists.pjsip.org>
Sent: Wednesday, October 10, 2007 6:51 PM
Subject: Re: [pjsip] pjsip for WM5/C#
> Hi Olivier,
>
> Olivier Beytrison wrote:
> > I still experience some issues :
> > - When calling pjsua_acc_del(accountID), the on_reg_state() callback
> > isn't called. Looking at the logs, pjsua delete the account before
> > receiving the 200 OK from the server, this preventing it from calling
> > the on_reg_state(pjsua_acc_id acc_id) callback, because the account
> > have already been deleted
>
> I think that's the expected behavior. From application's view, the
> deletion happens immediately. Once the account is deleted, it is
> gone as far as application is concerned, thus it will not hear any
> more callbacks called on behalf of the account.
>
> > - During a call, some times It doesn't send any sound. After putting on
> > hold the call, and retrieving it, the sounds works. And i get a lot
> > of BAD Ptr for the RTP session
>
> Not sure about this. Maybe you can get more information by following
> the troubleshooting procedure from the sound problem Wiki
> (http://www.pjsip.org/trac/wiki).
>
> > - when calling pjsua_call_hangup(), it takes most of the time 8 to 15
> > seconds for the call to hang up. Same goes when the other UA initiate
> > the hang up
>
> This sounds like problem with Contact header calculation. Maybe the
> IP address that is selected in Contact header is not the one that's
> reachable from remote UA.
>
> > About the IMS-Specific things for SIP, it is mainly Headers. (like the
> > P-Access-Info header which describe which kind of "connection" the
> > signaling is sent on, like 3gpp-umts-cell, wireless-network, ect ect). I
> > can give you a small overview of the 3gpp-specific headers if you're
> > interested.
>
> An IMS overview will be great! Not that I'm planning to implement
> them (just yet), but any free info is always good. :)
>
> cheers,
> -benny
>
> > That's it for now, work is going on for the GUI, and hopefully we should
> > have a beta version in about 1 week.
> >
> > Regards,
> >
> > Olivier B.
> >
>
>
> --
> Benny Prijono
> http://www.pjsip.org
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip@lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>