[Sofia-sip-devel] Sofia Sip using Visual Studio 2017

[gilles Djomo Sawa via Sofia-sip-devel]

Hello Community,
I am trying to implement something with Sofia SIP using VS 2017.Actually I get 
a lot of Issues. Can Someone help to solve?




May be a patch or some hints?
I thank you in Advance
Kind Regards
Gilles
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP 'master' repo

[Antonis Tsakiridis]

Hello again, reaching out to see if you had a look at my draft plan.

Best regards,
Antonis

On Mon, Jul 24, 2017 at 1:00 PM, Antonis Tsakiridis <
antonis.tsakiri...@telestax.com> wrote:

> Hello all,
>
> Here's a set of steps that come to mind:
>
>- Move Sofia SIP code to an open source repo.
>   - I would propose GitHub, as we have been working for it on our OSS
>   and it provides nice tools for collaboration as well as integrates with
>   virtually everything we might need. Some examples are Travis for CI, 
> Zenhub
>   for PM, etc. At this point would be very important to retain history.
>- Add CI facilities.
>   - I would suggest Travis CI that is free for OSS projects. It works
>   pretty well for Linux projects, and also provides iOS images if we are
>   interested in cross compilation. I know we do as we use Sofia for iOS.
>   - Run unit/integration tests as part of CI job. IIRC Sofia SIP
>   comes with a set of tests, but you guys are probably more knowledgeable 
> on
>   this
>   - We can setup CI either for each commit, or for Pull Requests
>   depending on what we need.
>   - Potentially store the built libraries somewhere so that they are
>   available for use. AFAIK Travis CI doesn't provide that sort of
>   functionality, but we can search around and see what is available.
>   - Cross-compile for iOS and upload to CocoaPods for easy
>   distribution to iOS. We can also consider alternatives as CocoaPods are
>   sometimes difficult to maintain.
>
> This is a rough list of things that we can build upon, so feel free to
> comment as you see fit
>
> Best regards,
> Antonis
>
>
> On Tue, Jul 18, 2017 at 12:51 PM, Antonis Tsakiridis <
> antonis.tsakiri...@telestax.com> wrote:
>
>> Ok cool Mike, I can try to come up with a draft of some activities to
>> move us in that direction and we can collaborate on that to get things
>> going.
>>
>> Best regards,
>> Antonis
>>
>> On Mon, Jul 17, 2017 at 6:39 PM, Michael Jerris  wrote:
>>
>>> Its still on my list…. but still not done.  Antonis, yeah, lets
>>> coordinate and see if we can figure out what needs to be done to make it
>>> happen.
>>>
>>> Mike
>>>
>>> On Jul 17, 2017, at 9:14 AM, Antonis Tsakiridis <
>>> antonis.tsakiri...@telestax.com> wrote:
>>>
>>> Ok thanks Moises for the useful feedback. I remember I had a discussion
>>> with Mike on hosting Sofia source independently of FreeSwitch, but I guess
>>> he didn't have time to organize this yet.
>>>
>>> @Mike, are there any updates on this?
>>>
>>> I think it would be invaluable to have a single place for Sofia (for
>>> example GitHub) where code is buildable and potentially testable (for
>>> example using Travis CI). Also with the advent of WebRTC + mobile we could
>>> all help in further adoption of Sofia in iOS (using CocoaPods potentially)
>>> + Android (potentially using JNI even though JAIN SIP is pretty used in
>>> Android world) and make the whole thing modular so that it's more easily
>>> usable in many platforms.
>>>
>>> At Telestax we have already integrated Sofia with iOS and using it with
>>> WebRTC for media for quite some time now, so I could definitely help in
>>> this effort on my free cycles.
>>>
>>> Best regards,
>>> Antonis
>>>
>>> On Thu, Jul 13, 2017 at 9:47 PM, Moises Silva 
>>> wrote:
>>>

>- Can I somehow differentiate commits that have to do with Sofia?
>I see 'mod_sofia' in some commits. Is that it? I guess I could probably
>come up with a git command to only show changes inside libs/sofia-sip, 
> but
>wondering if the Freeswich folks used a convention
>
> The stack proper is in libs/sofia-sip/, all you need is 'git log
 libs/sofia-sip'

>
>- Can I find the last commit before Sofia was merged into
>Freeswitch project? So that I can follow history and see which changes
>where made to Sofia after the merge? Also which version of Sofia was
>Freeswitch basedon? Is it 1.12.11
>
> 
>?
>
> No idea. Mike might know. Otherwise, you'll have to follow the git
 history and see if there are clues there.

>
>- If I were to take Sofia from within the Freeswitch project and
>copy it as an independent bundle, would autotools work in
>configuring/making/installing etc? Or have dependencies been introduced
>over time and now Sofia needs to have Freeswitch in order to work?
>
> I'm pretty sure there are no dependencies on FreeSWITCH, so you should
 be able to just compile the library alone and use it.

>>>
>>>
>>>
>>> --
>>> Antonis Tsakiridis
>>> Lead Developer, Mobile SDKs at Telestax
>>> antonis.tsakiri...@telestax.com
>>> www.telestax.com
>>>
>>>
>>>
>>
>>
>> --
>> Antonis Tsakiridis
>> Lead 

Re: [Sofia-sip-devel] Sofia SIP 'master' repo

[Antonis Tsakiridis]

Hello all,

Here's a set of steps that come to mind:

   - Move Sofia SIP code to an open source repo.
  - I would propose GitHub, as we have been working for it on our OSS
  and it provides nice tools for collaboration as well as integrates with
  virtually everything we might need. Some examples are Travis for
CI, Zenhub
  for PM, etc. At this point would be very important to retain history.
   - Add CI facilities.
  - I would suggest Travis CI that is free for OSS projects. It works
  pretty well for Linux projects, and also provides iOS images if we are
  interested in cross compilation. I know we do as we use Sofia for iOS.
  - Run unit/integration tests as part of CI job. IIRC Sofia SIP comes
  with a set of tests, but you guys are probably more knowledgeable on this
  - We can setup CI either for each commit, or for Pull Requests
  depending on what we need.
  - Potentially store the built libraries somewhere so that they are
  available for use. AFAIK Travis CI doesn't provide that sort of
  functionality, but we can search around and see what is available.
  - Cross-compile for iOS and upload to CocoaPods for easy distribution
  to iOS. We can also consider alternatives as CocoaPods are sometimes
  difficult to maintain.

This is a rough list of things that we can build upon, so feel free to
comment as you see fit

Best regards,
Antonis


On Tue, Jul 18, 2017 at 12:51 PM, Antonis Tsakiridis <
antonis.tsakiri...@telestax.com> wrote:

> Ok cool Mike, I can try to come up with a draft of some activities to move
> us in that direction and we can collaborate on that to get things going.
>
> Best regards,
> Antonis
>
> On Mon, Jul 17, 2017 at 6:39 PM, Michael Jerris  wrote:
>
>> Its still on my list…. but still not done.  Antonis, yeah, lets
>> coordinate and see if we can figure out what needs to be done to make it
>> happen.
>>
>> Mike
>>
>> On Jul 17, 2017, at 9:14 AM, Antonis Tsakiridis <
>> antonis.tsakiri...@telestax.com> wrote:
>>
>> Ok thanks Moises for the useful feedback. I remember I had a discussion
>> with Mike on hosting Sofia source independently of FreeSwitch, but I guess
>> he didn't have time to organize this yet.
>>
>> @Mike, are there any updates on this?
>>
>> I think it would be invaluable to have a single place for Sofia (for
>> example GitHub) where code is buildable and potentially testable (for
>> example using Travis CI). Also with the advent of WebRTC + mobile we could
>> all help in further adoption of Sofia in iOS (using CocoaPods potentially)
>> + Android (potentially using JNI even though JAIN SIP is pretty used in
>> Android world) and make the whole thing modular so that it's more easily
>> usable in many platforms.
>>
>> At Telestax we have already integrated Sofia with iOS and using it with
>> WebRTC for media for quite some time now, so I could definitely help in
>> this effort on my free cycles.
>>
>> Best regards,
>> Antonis
>>
>> On Thu, Jul 13, 2017 at 9:47 PM, Moises Silva 
>> wrote:
>>
>>>
- Can I somehow differentiate commits that have to do with Sofia? I
see 'mod_sofia' in some commits. Is that it? I guess I could probably 
 come
up with a git command to only show changes inside libs/sofia-sip, but
wondering if the Freeswich folks used a convention

 The stack proper is in libs/sofia-sip/, all you need is 'git log
>>> libs/sofia-sip'
>>>

- Can I find the last commit before Sofia was merged into
Freeswitch project? So that I can follow history and see which changes
where made to Sofia after the merge? Also which version of Sofia was
Freeswitch basedon? Is it 1.12.11

 
?

 No idea. Mike might know. Otherwise, you'll have to follow the git
>>> history and see if there are clues there.
>>>

- If I were to take Sofia from within the Freeswitch project and
copy it as an independent bundle, would autotools work in
configuring/making/installing etc? Or have dependencies been introduced
over time and now Sofia needs to have Freeswitch in order to work?

 I'm pretty sure there are no dependencies on FreeSWITCH, so you should
>>> be able to just compile the library alone and use it.
>>>
>>
>>
>>
>> --
>> Antonis Tsakiridis
>> Lead Developer, Mobile SDKs at Telestax
>> antonis.tsakiri...@telestax.com
>> www.telestax.com
>>
>>
>>
>
>
> --
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at Telestax
> antonis.tsakiri...@telestax.com
> www.telestax.com
>



-- 
Antonis Tsakiridis
Lead Developer, Mobile SDKs at Telestax
www.telestax.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 

Re: [Sofia-sip-devel] Sofia SIP 'master' repo

[Antonis Tsakiridis]

Ok cool Mike, I can try to come up with a draft of some activities to move
us in that direction and we can collaborate on that to get things going.

Best regards,
Antonis

On Mon, Jul 17, 2017 at 6:39 PM, Michael Jerris  wrote:

> Its still on my list…. but still not done.  Antonis, yeah, lets coordinate
> and see if we can figure out what needs to be done to make it happen.
>
> Mike
>
> On Jul 17, 2017, at 9:14 AM, Antonis Tsakiridis <
> antonis.tsakiri...@telestax.com> wrote:
>
> Ok thanks Moises for the useful feedback. I remember I had a discussion
> with Mike on hosting Sofia source independently of FreeSwitch, but I guess
> he didn't have time to organize this yet.
>
> @Mike, are there any updates on this?
>
> I think it would be invaluable to have a single place for Sofia (for
> example GitHub) where code is buildable and potentially testable (for
> example using Travis CI). Also with the advent of WebRTC + mobile we could
> all help in further adoption of Sofia in iOS (using CocoaPods potentially)
> + Android (potentially using JNI even though JAIN SIP is pretty used in
> Android world) and make the whole thing modular so that it's more easily
> usable in many platforms.
>
> At Telestax we have already integrated Sofia with iOS and using it with
> WebRTC for media for quite some time now, so I could definitely help in
> this effort on my free cycles.
>
> Best regards,
> Antonis
>
> On Thu, Jul 13, 2017 at 9:47 PM, Moises Silva 
> wrote:
>
>>
>>>- Can I somehow differentiate commits that have to do with Sofia? I
>>>see 'mod_sofia' in some commits. Is that it? I guess I could probably 
>>> come
>>>up with a git command to only show changes inside libs/sofia-sip, but
>>>wondering if the Freeswich folks used a convention
>>>
>>> The stack proper is in libs/sofia-sip/, all you need is 'git log
>> libs/sofia-sip'
>>
>>>
>>>- Can I find the last commit before Sofia was merged into Freeswitch
>>>project? So that I can follow history and see which changes where made to
>>>Sofia after the merge? Also which version of Sofia was Freeswitch 
>>> basedon?
>>>Is it 1.12.11
>>>
>>> 
>>>?
>>>
>>> No idea. Mike might know. Otherwise, you'll have to follow the git
>> history and see if there are clues there.
>>
>>>
>>>- If I were to take Sofia from within the Freeswitch project and
>>>copy it as an independent bundle, would autotools work in
>>>configuring/making/installing etc? Or have dependencies been introduced
>>>over time and now Sofia needs to have Freeswitch in order to work?
>>>
>>> I'm pretty sure there are no dependencies on FreeSWITCH, so you should
>> be able to just compile the library alone and use it.
>>
>
>
>
> --
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at Telestax
> antonis.tsakiri...@telestax.com
> www.telestax.com
>
>
>


-- 
Antonis Tsakiridis
Lead Developer, Mobile SDKs at Telestax
antonis.tsakiri...@telestax.com
www.telestax.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP 'master' repo

[Michael Jerris]

Its still on my list…. but still not done.  Antonis, yeah, lets coordinate and 
see if we can figure out what needs to be done to make it happen.

Mike

> On Jul 17, 2017, at 9:14 AM, Antonis Tsakiridis 
>  wrote:
> 
> Ok thanks Moises for the useful feedback. I remember I had a discussion with 
> Mike on hosting Sofia source independently of FreeSwitch, but I guess he 
> didn't have time to organize this yet.
> 
> @Mike, are there any updates on this?
> 
> I think it would be invaluable to have a single place for Sofia (for example 
> GitHub) where code is buildable and potentially testable (for example using 
> Travis CI). Also with the advent of WebRTC + mobile we could all help in 
> further adoption of Sofia in iOS (using CocoaPods potentially) + Android 
> (potentially using JNI even though JAIN SIP is pretty used in Android world) 
> and make the whole thing modular so that it's more easily usable in many 
> platforms. 
> 
> At Telestax we have already integrated Sofia with iOS and using it with 
> WebRTC for media for quite some time now, so I could definitely help in this 
> effort on my free cycles.
> 
> Best regards,
> Antonis
> 
> On Thu, Jul 13, 2017 at 9:47 PM, Moises Silva  > wrote:
> Can I somehow differentiate commits that have to do with Sofia? I see 
> 'mod_sofia' in some commits. Is that it? I guess I could probably come up 
> with a git command to only show changes inside libs/sofia-sip, but wondering 
> if the Freeswich folks used a convention
> The stack proper is in libs/sofia-sip/, all you need is 'git log 
> libs/sofia-sip'
> Can I find the last commit before Sofia was merged into Freeswitch project? 
> So that I can follow history and see which changes where made to Sofia after 
> the merge? Also which version of Sofia was Freeswitch basedon? Is it 1.12.11 
> ?
> No idea. Mike might know. Otherwise, you'll have to follow the git history 
> and see if there are clues there. 
> If I were to take Sofia from within the Freeswitch project and copy it as an 
> independent bundle, would autotools work in configuring/making/installing 
> etc? Or have dependencies been introduced over time and now Sofia needs to 
> have Freeswitch in order to work?
> I'm pretty sure there are no dependencies on FreeSWITCH, so you should be 
> able to just compile the library alone and use it.
> 
> 
> 
> -- 
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at Telestax
> antonis.tsakiri...@telestax.com 
> www.telestax.com 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP 'master' repo

[Moises Silva]

>
>
>- Can I somehow differentiate commits that have to do with Sofia? I
>see 'mod_sofia' in some commits. Is that it? I guess I could probably come
>up with a git command to only show changes inside libs/sofia-sip, but
>wondering if the Freeswich folks used a convention
>
> The stack proper is in libs/sofia-sip/, all you need is 'git log
libs/sofia-sip'

>
>- Can I find the last commit before Sofia was merged into Freeswitch
>project? So that I can follow history and see which changes where made to
>Sofia after the merge? Also which version of Sofia was Freeswitch basedon?
>Is it 1.12.11
>
> 
>?
>
> No idea. Mike might know. Otherwise, you'll have to follow the git history
and see if there are clues there.

>
>- If I were to take Sofia from within the Freeswitch project and copy
>it as an independent bundle, would autotools work in
>configuring/making/installing etc? Or have dependencies been introduced
>over time and now Sofia needs to have Freeswitch in order to work?
>
> I'm pretty sure there are no dependencies on FreeSWITCH, so you should be
able to just compile the library alone and use it.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip-devel Digest, Vol 96, Issue 2

[Dave Horton]

Just as an FYI, I forked sofia a while back from freeswitch, mainly because my 
use of sofia is heavily nta-based while freeswitch is nua-based, and I needed 
various enhancements / fixes.  Anyone is welcome to use / contribute if they 
like

https://github.com/davehorton/sofia-sip 
<https://github.com/davehorton/sofia-sip>

On Jul 12, 2017, at 8:07 AM, sofia-sip-devel-requ...@lists.sourceforge.net 
wrote:

Send Sofia-sip-devel mailing list submissions to
sofia-sip-devel@lists.sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
or, via email, send a message with subject or body 'help' to
sofia-sip-devel-requ...@lists.sourceforge.net

You can reach the person managing the list at
sofia-sip-devel-ow...@lists.sourceforge.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sofia-sip-devel digest..."
Today's Topics:

  1. Re: Sofia SIP 'master' repo (Antonis Tsakiridis)

From: Antonis Tsakiridis <antonis.tsakiri...@telestax.com>
Subject: Re: [Sofia-sip-devel] Sofia SIP 'master' repo
Date: July 12, 2017 at 7:53:42 AM EDT
To: Moises Silva <moises.si...@gmail.com>, Michael Jerris <m...@jerris.com>
Cc: "sofia-sip-devel@lists.sourceforge.net List" 
<sofia-sip-devel@lists.sourceforge.net>


Thanks Moises for the quick answer. I found Sofia inside the Freeswitch source, 
which is great, but I'm wondering about the following:
Can I somehow differentiate commits that have to do with Sofia? I see 
'mod_sofia' in some commits. Is that it? I guess I could probably come up with 
a git command to only show changes inside libs/sofia-sip, but wondering if the 
Freeswich folks used a convention
Can I find the last commit before Sofia was merged into Freeswitch project? So 
that I can follow history and see which changes where made to Sofia after the 
merge? Also which version of Sofia was Freeswitch basedon? Is it 1.12.11 
<https://gitorious.org/sofia-sip/sofia-sip?p=sofia-sip:sofia-sip.git;a=shortlog;h=refs/tags/1.12.11>?
If I were to take Sofia from within the Freeswitch project and copy it as an 
independent bundle, would autotools work in configuring/making/installing etc? 
Or have dependencies been introduced over time and now Sofia needs to have 
Freeswitch in order to work?
Best regards and thanks in advance,
Antonis

On Mon, Jul 10, 2017 at 2:48 PM, Moises Silva <moises.si...@gmail.com 
<mailto:moises.si...@gmail.com>> wrote:
On Mon, Jul 10, 2017 at 6:44 AM, Antonis Tsakiridis 
<antonis.tsakiri...@telestax.com <mailto:antonis.tsakiri...@telestax.com>> 
wrote:
Hello, is there a master repo for Sofia SIP that is considered active and 
current? If so can you share where I can find it?

I think libsofia inside the FreeSWITCH git repo si the most up to date.



-- 
Antonis Tsakiridis
Lead Developer, Mobile SDKs at Telestax
antonis.tsakiri...@telestax.com <mailto:antonis.tsakiri...@telestax.com>
http://www.telestax.com <http://www.telestax.com/>



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! 
http://sdm.link/slashdot___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP 'master' repo

[Antonis Tsakiridis]

Thanks Moises for the quick answer. I found Sofia inside the Freeswitch
source, which is great, but I'm wondering about the following:

   - Can I somehow differentiate commits that have to do with Sofia? I see
   'mod_sofia' in some commits. Is that it? I guess I could probably come up
   with a git command to only show changes inside libs/sofia-sip, but
   wondering if the Freeswich folks used a convention
   - Can I find the last commit before Sofia was merged into Freeswitch
   project? So that I can follow history and see which changes where made to
   Sofia after the merge? Also which version of Sofia was Freeswitch basedon?
   Is it 1.12.11
   

   ?
   - If I were to take Sofia from within the Freeswitch project and copy it
   as an independent bundle, would autotools work in
   configuring/making/installing etc? Or have dependencies been introduced
   over time and now Sofia needs to have Freeswitch in order to work?

Best regards and thanks in advance,
Antonis

On Mon, Jul 10, 2017 at 2:48 PM, Moises Silva 
wrote:

> On Mon, Jul 10, 2017 at 6:44 AM, Antonis Tsakiridis <
> antonis.tsakiri...@telestax.com> wrote:
>
>> Hello, is there a master repo for Sofia SIP that is considered active and
>> current? If so can you share where I can find it?
>>
>
> I think libsofia inside the FreeSWITCH git repo si the most up to date.
>



-- 
Antonis Tsakiridis
Lead Developer, Mobile SDKs at Telestax
antonis.tsakiri...@telestax.com
http://www.telestax.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP 'master' repo

[Moises Silva]

On Mon, Jul 10, 2017 at 6:44 AM, Antonis Tsakiridis <
antonis.tsakiri...@telestax.com> wrote:

> Hello, is there a master repo for Sofia SIP that is considered active and
> current? If so can you share where I can find it?
>

I think libsofia inside the FreeSWITCH git repo si the most up to date.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Sofia SIP 'master' repo

[Antonis Tsakiridis]

Hello, is there a master repo for Sofia SIP that is considered active and
current? If so can you share where I can find it?

Thanks,
Antonis Tsakiridis
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP integration with WebRTC & BoringSSL for iOS

[Antonis Tsakiridis]

Actually we have already ported Sofia for iOS and it's been working really
nice so far, combined with Webrtc for media ;). You can install it directly
on an iOS device from https://tsfr.io/xex2zc if you want to play with it,
and check code at https://github.com/RestComm/restcomm-ios-sdk -it's open
source. What we want to do though it to make integration easier for the iOS
Developer that wants to use just the Sofia part. Hence I said that we want
to come up with a more reusable API.

Anyway, thanks for for your input, we 'll be in touch :)

Antonis

On Fri, May 20, 2016 at 5:20 PM, Michael Jerris  wrote:

> I haven't done any porting but seeing as this ha been well ported to
> symbian, I think from day one, it should be well suited for it.  All that
> should be down in su layer
>
>
> On Friday, May 20, 2016, Antonis Tsakiridis <
> antonis.tsakiri...@telestax.com> wrote:
>
>> Great, having an up to date standalone repo that interested contributors
>> can use will help a lot to keep Sofia alive and kicking :)
>>
>> Glad I found someone who knows his way around autotools, will ping you
>> when I start working for next iOS version to get this fixed; hopefully you
>> will have managed to create the repo by then so that I can contribute it
>> back ;)
>>
>> One more thing. Do you guys have experience porting Sofia on mobile
>> platforms? Would be a nice area to exchange experiences and help each
>> other. In Telestax we 're also thinking of coming up with a more reusable
>> API or even SDK over Sofia SIP, suitable for iOS developers that will make
>> it easy for community to take advantage of SIP functionality. Sofia has
>> proven great for our needs so far, but it's integration in iOS presents a
>> lot of challenges for newcomers. Would be nice to simplify that.
>>
>> Best regards,
>> Antonis
>>
>> On Thu, May 19, 2016 at 6:31 PM, Michael Jerris  wrote:
>>
>>> The closest to a central maintained repo at this point is the copy in
>>> the freeswitch tree.  We will pull this out into a standalone repo sometime
>>> this summer before we do our next major version.  Unfortunately it seems
>>> like we are the last ones doing any maintaining of sofia-sip.  Making a way
>>> to choose between the two seems sane.  I'm probably the autotools guy who
>>> can help... Talk to me offline and I can look at the patches and send you
>>> in the right direction on how to resolve this.  The big issue with the
>>> sofia-sip in the freeswitch tree currently is that its set to build as a
>>> convenience lib not a normal libtool lib, I'll have to change that back and
>>> then make it an option too.
>>>
>>>
>>> On May 19, 2016, at 4:52 AM, Antonis Tsakiridis <
>>> antonis.tsakiri...@telestax.com> wrote:
>>>
>>> Hi Michael,
>>>
>>> First off, sorry for the late reply. Ok so what I did was to essentially
>>> replace openssl with boringssl in the auto tools build scripts and then
>>> allow Sofia to gather it's dependencies from the webrtc static lib that
>>> includes boringssl. Some points:
>>>
>>>- Been trying to figure our a 'central' repository for Sofia SIP
>>>code, so that I can contribute back to, but haven't been able to. I seem 
>>> to
>>>recall a gitorious repo but that doesn't seem to be around anymore. I see
>>>that you have been involved with Sofia for the Freeswitch project, so 
>>> maybe
>>>you can give me some pointers?
>>>- Before contributing back I'd like to improve my contribution so
>>>that instead of replacing openssl with boringssl, to add it on top, so 
>>> that
>>>a developer can chose during configure time which of the two they need. 
>>> The
>>>problem is that I'm not that proficient with auto tools and it would take
>>>me forever to do so. Do you have auto tools know-how? If so would you be
>>>interested in contributing that part your self so that the community can
>>>benefit from a more generic solution?
>>>
>>> Best regards,
>>> Antonis
>>>
>>> On Mon, Feb 15, 2016 at 5:31 PM, Michael Jerris  wrote:
>>>
 I'm interested


 On Monday, February 15, 2016, Antonis Tsakiridis <
 antonis.tsakiri...@telestax.com> wrote:

> Hello,
>
> I just wanted to let you know that we 've been working with Sofia SIP
> and successfully combined it with Google's WebRTC native library for iOS
> and lately we managed to integrate the TLS part also.
>
> We did have some issues on the TLS integration due to the fact that
> Sofia is configured to work with OpenSSL, while WebRTC library already
> includes BoringSSL, and putting them all together was causing us trouble.
> So our solution was to change the auto tools configuration so that instead
> of OpenSSL it uses WebRTC library which includes Boring SSL and that did
> the trick. Would you be interested in such integration?
>
> Best regards
>
> --
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at 

Re: [Sofia-sip-devel] Sofia SIP integration with WebRTC & BoringSSL for iOS

[Michael Jerris]

I haven't done any porting but seeing as this ha been well ported to
symbian, I think from day one, it should be well suited for it.  All that
should be down in su layer

On Friday, May 20, 2016, Antonis Tsakiridis 
wrote:

> Great, having an up to date standalone repo that interested contributors
> can use will help a lot to keep Sofia alive and kicking :)
>
> Glad I found someone who knows his way around autotools, will ping you
> when I start working for next iOS version to get this fixed; hopefully you
> will have managed to create the repo by then so that I can contribute it
> back ;)
>
> One more thing. Do you guys have experience porting Sofia on mobile
> platforms? Would be a nice area to exchange experiences and help each
> other. In Telestax we 're also thinking of coming up with a more reusable
> API or even SDK over Sofia SIP, suitable for iOS developers that will make
> it easy for community to take advantage of SIP functionality. Sofia has
> proven great for our needs so far, but it's integration in iOS presents a
> lot of challenges for newcomers. Would be nice to simplify that.
>
> Best regards,
> Antonis
>
> On Thu, May 19, 2016 at 6:31 PM, Michael Jerris  > wrote:
>
>> The closest to a central maintained repo at this point is the copy in the
>> freeswitch tree.  We will pull this out into a standalone repo sometime
>> this summer before we do our next major version.  Unfortunately it seems
>> like we are the last ones doing any maintaining of sofia-sip.  Making a way
>> to choose between the two seems sane.  I'm probably the autotools guy who
>> can help... Talk to me offline and I can look at the patches and send you
>> in the right direction on how to resolve this.  The big issue with the
>> sofia-sip in the freeswitch tree currently is that its set to build as a
>> convenience lib not a normal libtool lib, I'll have to change that back and
>> then make it an option too.
>>
>>
>> On May 19, 2016, at 4:52 AM, Antonis Tsakiridis <
>> antonis.tsakiri...@telestax.com
>> > wrote:
>>
>> Hi Michael,
>>
>> First off, sorry for the late reply. Ok so what I did was to essentially
>> replace openssl with boringssl in the auto tools build scripts and then
>> allow Sofia to gather it's dependencies from the webrtc static lib that
>> includes boringssl. Some points:
>>
>>- Been trying to figure our a 'central' repository for Sofia SIP
>>code, so that I can contribute back to, but haven't been able to. I seem 
>> to
>>recall a gitorious repo but that doesn't seem to be around anymore. I see
>>that you have been involved with Sofia for the Freeswitch project, so 
>> maybe
>>you can give me some pointers?
>>- Before contributing back I'd like to improve my contribution so
>>that instead of replacing openssl with boringssl, to add it on top, so 
>> that
>>a developer can chose during configure time which of the two they need. 
>> The
>>problem is that I'm not that proficient with auto tools and it would take
>>me forever to do so. Do you have auto tools know-how? If so would you be
>>interested in contributing that part your self so that the community can
>>benefit from a more generic solution?
>>
>> Best regards,
>> Antonis
>>
>> On Mon, Feb 15, 2016 at 5:31 PM, Michael Jerris > > wrote:
>>
>>> I'm interested
>>>
>>>
>>> On Monday, February 15, 2016, Antonis Tsakiridis <
>>> antonis.tsakiri...@telestax.com
>>> >
>>> wrote:
>>>
 Hello,

 I just wanted to let you know that we 've been working with Sofia SIP
 and successfully combined it with Google's WebRTC native library for iOS
 and lately we managed to integrate the TLS part also.

 We did have some issues on the TLS integration due to the fact that
 Sofia is configured to work with OpenSSL, while WebRTC library already
 includes BoringSSL, and putting them all together was causing us trouble.
 So our solution was to change the auto tools configuration so that instead
 of OpenSSL it uses WebRTC library which includes Boring SSL and that did
 the trick. Would you be interested in such integration?

 Best regards

 --
 Antonis Tsakiridis
 Lead Developer, Mobile SDKs at TeleStax
 antonis.tsakiri...@telestax.com
 http://www.telestax.com


>>
>>
>> --
>> Antonis Tsakiridis
>> Lead Developer, Mobile SDKs at TeleStax
>> antonis.tsakiri...@telestax.com
>> 
>> http://www.telestax.com
>>
>>
>>
>
>
> --
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at TeleStax
> antonis.tsakiri...@telestax.com
> 
> 

Re: [Sofia-sip-devel] Sofia SIP integration with WebRTC & BoringSSL for iOS

[Antonis Tsakiridis]

Great, having an up to date standalone repo that interested contributors
can use will help a lot to keep Sofia alive and kicking :)

Glad I found someone who knows his way around autotools, will ping you when
I start working for next iOS version to get this fixed; hopefully you will
have managed to create the repo by then so that I can contribute it back ;)

One more thing. Do you guys have experience porting Sofia on mobile
platforms? Would be a nice area to exchange experiences and help each
other. In Telestax we 're also thinking of coming up with a more reusable
API or even SDK over Sofia SIP, suitable for iOS developers that will make
it easy for community to take advantage of SIP functionality. Sofia has
proven great for our needs so far, but it's integration in iOS presents a
lot of challenges for newcomers. Would be nice to simplify that.

Best regards,
Antonis

On Thu, May 19, 2016 at 6:31 PM, Michael Jerris  wrote:

> The closest to a central maintained repo at this point is the copy in the
> freeswitch tree.  We will pull this out into a standalone repo sometime
> this summer before we do our next major version.  Unfortunately it seems
> like we are the last ones doing any maintaining of sofia-sip.  Making a way
> to choose between the two seems sane.  I'm probably the autotools guy who
> can help... Talk to me offline and I can look at the patches and send you
> in the right direction on how to resolve this.  The big issue with the
> sofia-sip in the freeswitch tree currently is that its set to build as a
> convenience lib not a normal libtool lib, I'll have to change that back and
> then make it an option too.
>
>
> On May 19, 2016, at 4:52 AM, Antonis Tsakiridis <
> antonis.tsakiri...@telestax.com> wrote:
>
> Hi Michael,
>
> First off, sorry for the late reply. Ok so what I did was to essentially
> replace openssl with boringssl in the auto tools build scripts and then
> allow Sofia to gather it's dependencies from the webrtc static lib that
> includes boringssl. Some points:
>
>- Been trying to figure our a 'central' repository for Sofia SIP code,
>so that I can contribute back to, but haven't been able to. I seem to
>recall a gitorious repo but that doesn't seem to be around anymore. I see
>that you have been involved with Sofia for the Freeswitch project, so maybe
>you can give me some pointers?
>- Before contributing back I'd like to improve my contribution so that
>instead of replacing openssl with boringssl, to add it on top, so that a
>developer can chose during configure time which of the two they need. The
>problem is that I'm not that proficient with auto tools and it would take
>me forever to do so. Do you have auto tools know-how? If so would you be
>interested in contributing that part your self so that the community can
>benefit from a more generic solution?
>
> Best regards,
> Antonis
>
> On Mon, Feb 15, 2016 at 5:31 PM, Michael Jerris  wrote:
>
>> I'm interested
>>
>>
>> On Monday, February 15, 2016, Antonis Tsakiridis <
>> antonis.tsakiri...@telestax.com> wrote:
>>
>>> Hello,
>>>
>>> I just wanted to let you know that we 've been working with Sofia SIP
>>> and successfully combined it with Google's WebRTC native library for iOS
>>> and lately we managed to integrate the TLS part also.
>>>
>>> We did have some issues on the TLS integration due to the fact that
>>> Sofia is configured to work with OpenSSL, while WebRTC library already
>>> includes BoringSSL, and putting them all together was causing us trouble.
>>> So our solution was to change the auto tools configuration so that instead
>>> of OpenSSL it uses WebRTC library which includes Boring SSL and that did
>>> the trick. Would you be interested in such integration?
>>>
>>> Best regards
>>>
>>> --
>>> Antonis Tsakiridis
>>> Lead Developer, Mobile SDKs at TeleStax
>>> antonis.tsakiri...@telestax.com
>>> http://www.telestax.com
>>>
>>>
>
>
> --
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at TeleStax
> antonis.tsakiri...@telestax.com
> http://www.telestax.com
>
>
>


-- 
Antonis Tsakiridis
Lead Developer, Mobile SDKs at TeleStax
antonis.tsakiri...@telestax.com
http://www.telestax.com
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP integration with WebRTC & BoringSSL for iOS

[Michael Jerris]

The closest to a central maintained repo at this point is the copy in the 
freeswitch tree.  We will pull this out into a standalone repo sometime this 
summer before we do our next major version.  Unfortunately it seems like we are 
the last ones doing any maintaining of sofia-sip.  Making a way to choose 
between the two seems sane.  I'm probably the autotools guy who can help... 
Talk to me offline and I can look at the patches and send you in the right 
direction on how to resolve this.  The big issue with the sofia-sip in the 
freeswitch tree currently is that its set to build as a convenience lib not a 
normal libtool lib, I'll have to change that back and then make it an option 
too.


> On May 19, 2016, at 4:52 AM, Antonis Tsakiridis 
>  wrote:
> 
> Hi Michael, 
> 
> First off, sorry for the late reply. Ok so what I did was to essentially 
> replace openssl with boringssl in the auto tools build scripts and then allow 
> Sofia to gather it's dependencies from the webrtc static lib that includes 
> boringssl. Some points:
> Been trying to figure our a 'central' repository for Sofia SIP code, so that 
> I can contribute back to, but haven't been able to. I seem to recall a 
> gitorious repo but that doesn't seem to be around anymore. I see that you 
> have been involved with Sofia for the Freeswitch project, so maybe you can 
> give me some pointers?
> Before contributing back I'd like to improve my contribution so that instead 
> of replacing openssl with boringssl, to add it on top, so that a developer 
> can chose during configure time which of the two they need. The problem is 
> that I'm not that proficient with auto tools and it would take me forever to 
> do so. Do you have auto tools know-how? If so would you be interested in 
> contributing that part your self so that the community can benefit from a 
> more generic solution?
> Best regards,
> Antonis
> 
> On Mon, Feb 15, 2016 at 5:31 PM, Michael Jerris  > wrote:
> I'm interested
> 
> 
> On Monday, February 15, 2016, Antonis Tsakiridis 
> > 
> wrote:
> Hello, 
> 
> I just wanted to let you know that we 've been working with Sofia SIP and 
> successfully combined it with Google's WebRTC native library for iOS and 
> lately we managed to integrate the TLS part also. 
> 
> We did have some issues on the TLS integration due to the fact that Sofia is 
> configured to work with OpenSSL, while WebRTC library already includes 
> BoringSSL, and putting them all together was causing us trouble. So our 
> solution was to change the auto tools configuration so that instead of 
> OpenSSL it uses WebRTC library which includes Boring SSL and that did the 
> trick. Would you be interested in such integration?
> 
> Best regards 
> 
> -- 
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at TeleStax
> antonis.tsakiri...@telestax.com <>
> http://www.telestax.com 
> 
> 
> 
> 
> -- 
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at TeleStax
> antonis.tsakiri...@telestax.com 
> http://www.telestax.com 
> 

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP integration with WebRTC & BoringSSL for iOS

[Antonis Tsakiridis]

Hi Michael,

First off, sorry for the late reply. Ok so what I did was to essentially
replace openssl with boringssl in the auto tools build scripts and then
allow Sofia to gather it's dependencies from the webrtc static lib that
includes boringssl. Some points:

   - Been trying to figure our a 'central' repository for Sofia SIP code,
   so that I can contribute back to, but haven't been able to. I seem to
   recall a gitorious repo but that doesn't seem to be around anymore. I see
   that you have been involved with Sofia for the Freeswitch project, so maybe
   you can give me some pointers?
   - Before contributing back I'd like to improve my contribution so that
   instead of replacing openssl with boringssl, to add it on top, so that a
   developer can chose during configure time which of the two they need. The
   problem is that I'm not that proficient with auto tools and it would take
   me forever to do so. Do you have auto tools know-how? If so would you be
   interested in contributing that part your self so that the community can
   benefit from a more generic solution?

Best regards,
Antonis

On Mon, Feb 15, 2016 at 5:31 PM, Michael Jerris  wrote:

> I'm interested
>
>
> On Monday, February 15, 2016, Antonis Tsakiridis <
> antonis.tsakiri...@telestax.com> wrote:
>
>> Hello,
>>
>> I just wanted to let you know that we 've been working with Sofia SIP and
>> successfully combined it with Google's WebRTC native library for iOS and
>> lately we managed to integrate the TLS part also.
>>
>> We did have some issues on the TLS integration due to the fact that Sofia
>> is configured to work with OpenSSL, while WebRTC library already includes
>> BoringSSL, and putting them all together was causing us trouble. So our
>> solution was to change the auto tools configuration so that instead of
>> OpenSSL it uses WebRTC library which includes Boring SSL and that did the
>> trick. Would you be interested in such integration?
>>
>> Best regards
>>
>> --
>> Antonis Tsakiridis
>> Lead Developer, Mobile SDKs at TeleStax
>> antonis.tsakiri...@telestax.com
>> http://www.telestax.com
>>
>>


-- 
Antonis Tsakiridis
Lead Developer, Mobile SDKs at TeleStax
antonis.tsakiri...@telestax.com
http://www.telestax.com
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP integration with WebRTC & BoringSSL for iOS

[Michael Jerris]

I'm interested

On Monday, February 15, 2016, Antonis Tsakiridis <
antonis.tsakiri...@telestax.com> wrote:

> Hello,
>
> I just wanted to let you know that we 've been working with Sofia SIP and
> successfully combined it with Google's WebRTC native library for iOS and
> lately we managed to integrate the TLS part also.
>
> We did have some issues on the TLS integration due to the fact that Sofia
> is configured to work with OpenSSL, while WebRTC library already includes
> BoringSSL, and putting them all together was causing us trouble. So our
> solution was to change the auto tools configuration so that instead of
> OpenSSL it uses WebRTC library which includes Boring SSL and that did the
> trick. Would you be interested in such integration?
>
> Best regards
>
> --
> Antonis Tsakiridis
> Lead Developer, Mobile SDKs at TeleStax
> antonis.tsakiri...@telestax.com
> 
> http://www.telestax.com
>
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip

[Thomas Volkert]

Hello,

Great! For a long time, I am now a passive reader of this mailing list. 
I really like this new step of Sofia-SIP.
Is there already a vision how Sofia-SIP will be changed, especially, if 
the API/ABI of Sofia-SIP will  be changed in the near future?

Best regards,
Thomas.


On 14.08.2014 21:23, Kai Vehmanen wrote:
 Hi,

 On Thu, 14 Aug 2014, Kai Vehmanen wrote:

 As the first step, I'd like to add you Mike as a admin of the sf.net
 project that hosts the current website. You have by far most merged
 this is done now, Mike added as an admin.

 --
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip

[Michael Jerris]

I wouldn't plan on any, as i said, the next step is a volunteer to review the 
changes made in the freeswitch tree so we can re-release that as something 
others can use without breakage.

On Aug 15, 2014, at 8:39 AM, Thomas Volkert si...@gmx.net wrote:

 Hello,
 
 Great! For a long time, I am now a passive reader of this mailing list. 
 I really like this new step of Sofia-SIP.
 Is there already a vision how Sofia-SIP will be changed, especially, if 
 the API/ABI of Sofia-SIP will  be changed in the near future?
 
 Best regards,
 Thomas.
 
 
 On 14.08.2014 21:23, Kai Vehmanen wrote:
 Hi,
 
 On Thu, 14 Aug 2014, Kai Vehmanen wrote:
 
 As the first step, I'd like to add you Mike as a admin of the sf.net
 project that hosts the current website. You have by far most merged
 this is done now, Mike added as an admin.
 


--
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip

[Kai Vehmanen]

Hi,

On Thu, 14 Aug 2014, Kai Vehmanen wrote:

 As the first step, I'd like to add you Mike as a admin of the sf.net
 project that hosts the current website. You have by far most merged

this is done now, Mike added as an admin.

--
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip

[Kai Vehmanen]

Hi,

On Mon, 11 Aug 2014, Michael Jerris wrote:

 Kai!  long time no talk.  I'm fine with whatever folks want, just need a 
 little help as far as manpower to clean up what we have back to 
 something usable outside freeswitch.

sorry for the long silence. I've been kind of hoping somebody from the 
original team could have picked up and continued the coordination work, 
but that does not seem to happen (at least I can state I don't have the 
time and possibility to take this role), so indeed time to arrange for 
something else.

As the first step, I'd like to add you Mike as a admin of the sf.net 
project that hosts the current website. You have by far most merged 
patches in current codebase out of those still actively participating on 
the list. Even if you don't take over directly, you have the possibility 
to pass the project onwards (or at least add a redirect to the FreeSWITCH 
branch).

I understand there are concerns with moving completely to FreeSWITCH for 
those who've been using sofia-sip for other purposes, but there is quite a 
lot involved in running a full independent project. With FreeSWITCH, the 
codebase could be maintained with potentially less overhead, and in 
exchange for making the Sofia-SIP instance in FreeSWITCH tree more 
generally usable (if anything is needed to begin with to that end), 
FreeSWITCH infra could be used to review and merge patches to a single 
trunk (from the many gitorious trees that exist now). So potentially 
win-win for all involved.

But yeah, maybe I shouldn't intervene/propose anything beyond this, 
it's upto you who continue to decide.

--
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip

[Michael Jerris]

Kai!  long time no talk.  I'm fine with whatever folks want, just need a little 
help as far as manpower to clean up what we have back to something usable 
outside freeswitch.

Mike

On Aug 10, 2014, at 11:13 AM, Kai Vehmanen kvli...@nosignal.fi wrote:

 Hi,
 
 [resend to list]
 
 On Sat, 9 Aug 2014, Nikos Balkanas wrote:
 
 Apparently kaiv is a sofia-sip active administrator, according to 
 sourceforge ops. Do they mean list moderator?
 Do you know him?
 
 I'm still here. :)
 
 I still have admin rights to both the SF and gitorious projects (except 
 for the SF net mailing list, only Pekka has the admin password). If there 
 is interest to take the project over, I can help with the transition. 
 Ideally I'd like to get an ack from Pekka (and Mike), but let's see if I 
 can reach him still.
 
 For all practical purposes, the version of Sofia-SIP in FreeSWITCH trunk 
 is the new upstream for the project, but I agree updating the old website 
 to reflect this would be appropriate (and avoid confusion).
 
 --
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel


--
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip and H.323

[Nikos Balkanas]

On Fri, Jun 20, 2014 at 5:51 PM, Michael Jerris m...@jerris.com wrote:

 sofia-sip is fine for pretty much any sip you need, however it seems very
 strange to me that you would need both h.323 and sip for anything at the
 same time.  Are you sure you understand the requirements.  If you are
 looking for a head start, you might want to try to build this application
 using freeswitch (www.freeswitch.org) as it already supports both sip and
 h.323.

 Mike


​Thanks Mike, for your fast response.

I may be wrong, but my understanding is that you need H323 for phone
signalling, i.e. to make phone ring (or deliver the SMS). If you say that
this can be handled over sip alone, all the better ;-)

​

 On Jun 20, 2014, at 3:06 AM, Nikos Balkanas nbalka...@gmail.com wrote:

 Hi,

 I am developing a Voip smsc. I need to send sms over voip. I am new to
 sofia. If I understand correctly, i need H.323 to call another phone and
 then sip to transmit the sms. I am not interested in voice communication,
 although a response dlr (delivery report) is required.

 Is sofia-sip suitable for my task? Or is it, as its name suggests, only
 SIP?

 TIA,
 Nikos

 --
 HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
 Find What Matters Most in Your Big Data with HPCC Systems
 Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
 Leverages Graph Analysis for Fast Processing  Easy Data Exploration

 http://p.sf.net/sfu/hpccsystems___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel



--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip and H.323

[Nikos Balkanas]

On Fri, Jun 20, 2014 at 10:34 PM, Michael Jerris m...@jerris.com wrote:

 I don't know the requirements for voip smsc, its not really a defined
 term, it just seems weird, so you should double check.



​Already checked out freeswitch. It's an overkill for my purposes. Sofia is
a SIP client, which fits me perfectly, if it just can dial out other phones.
The term, you haven't heard, because it doesn't exist, yet. It is my
contribution to the field;-)​

On Jun 20, 2014, at 3:31 PM, Nikos Balkanas nbalka...@gmail.com wrote:




 On Fri, Jun 20, 2014 at 5:51 PM, Michael Jerris m...@jerris.com wrote:

 sofia-sip is fine for pretty much any sip you need, however it seems very
 strange to me that you would need both h.323 and sip for anything at the
 same time.  Are you sure you understand the requirements.  If you are
 looking for a head start, you might want to try to build this application
 using freeswitch (www.freeswitch.org) as it already supports both sip
 and h.323.

 Mike


 ​Thanks Mike, for your fast response.

 I may be wrong, but my understanding is that you need H323 for phone
 signalling, i.e. to make phone ring (or deliver the SMS). If you say that
 this can be handled over sip alone, all the better ;-)

 ​

 On Jun 20, 2014, at 3:06 AM, Nikos Balkanas nbalka...@gmail.com wrote:

 Hi,

 I am developing a Voip smsc. I need to send sms over voip. I am new to
 sofia. If I understand correctly, i need H.323 to call another phone and
 then sip to transmit the sms. I am not interested in voice communication,
 although a response dlr (delivery report) is required.

 Is sofia-sip suitable for my task? Or is it, as its name suggests, only
 SIP?

 TIA,
 Nikos


--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip and H.323

[Roger Schreiter]

Am 20.06.2014 21:31, schrieb Nikos Balkanas:
 ...
 I may be wrong, but my understanding is that you need H323 for phone
 signalling, i.e. to make phone ring (or deliver the SMS). If you say
 that this can be handled over sip alone, all the better ;-)


Hi,

have a look at the message sample code at:
http://sofia-sip.sourceforge.net/refdocs/nua/

It shows (simplified), how to use SIP method message.


SMS via SIP is sent using this method.

Regards,
Roger.

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP for Windows - DLL

[Thomas Volkert]

Hello,

Have you also compiled it for Win64? Did it work?

Best regards,
Thomas.

On 04.11.2013 14:11, Michael Jerris wrote:
 It builds find using msvc.

 Mike

 On Nov 3, 2013, at 6:44 AM, natalia Zakowka natzako...@gmail.com wrote:

 Hello,

 I would like to use Sofia Sip on Windows XP.

 I compile using GCC and I would like to have a DLL for using it.

 Would you know if a port (dll file) maybe be found?

 Thank you in advance and best regards,
 Nat.



--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia SIP for Windows - DLL

[Michael Jerris]

Yes

On Nov 4, 2013, at 8:51 AM, Thomas Volkert si...@gmx.net wrote:

 Hello,
 
 Have you also compiled it for Win64? Did it work?
 
 Best regards,
 Thomas.
 
 On 04.11.2013 14:11, Michael Jerris wrote:
 It builds find using msvc.
 
 Mike
 
 On Nov 3, 2013, at 6:44 AM, natalia Zakowka natzako...@gmail.com wrote:
 
 Hello,
 
 I would like to use Sofia Sip on Windows XP.
 
 I compile using GCC and I would like to have a DLL for using it.
 
 Would you know if a port (dll file) maybe be found?
 
 Thank you in advance and best regards,
 Nat.
 
 


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Sofia SIP for Windows - DLL

[natalia Zakowka]

Hello,

I would like to use Sofia Sip on Windows XP.

I compile using GCC and I would like to have a DLL for using it.

Would you know if a port (dll file) maybe be found?

Thank you in advance and best regards,
Nat.
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Patches-3604466 ] Support of RFC 3455

[SourceForge . net]

Patches item #3604466, was opened at 2013-02-13 02:42
Message generated for change (Tracker Item Submitted) made by babass123
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756078aid=3604466group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bastien Bailly (babass123)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support of RFC 3455

Initial Comment:
With this patch Sofia-SIP stack will be able to handle SIP headers of RFC 3455 
'Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) 
for the 3rd-Generation Partnership Project (3GPP)'
Following headers should be supported:
P-Associated-URI
P-Called-Party-ID
P-Visited-Network-ID
P-Access-Network-Info
P-Charging-Function-Addresses
P-Charging-Vector

To use these headers sip_update_default_mclass(sip_extend_mclass(NULL)); must 
be called before entity creation.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756078aid=3604466group_id=143636

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Sofia Sip Win64

[Martin Staas]

Hey,

is there any Tutorial on how to compile Sofia Sip for a 64 Bit application
under Windows?

I  tried to set the Platform to x64 in VS2010 and downloaded pthread
lib/dll and header with x64 support.
But when i compile i get the following error(s):

1..\..\libsofia-sip-ua\url\url_tag.c(67): error C2220: warning treated as
error - no 'object' file generated
1..\..\libsofia-sip-ua\url\url_tag.c(67): warning C4306: 'type cast' :
conversion from 'int' to 'url_t *' of greater size
1..\..\libsofia-sip-ua\url\url_tag.c(79): warning C4306: 'type cast' :
conversion from 'int' to 'url_t *' of greater size
[...]
1[...]\libsofia-sip-ua\http\sofia-sip/http_header.h(195): error C2220:
warning treated as error - no 'object' file generated
1[...]\libsofia-sip-ua\http\sofia-sip/http_header.h(195): warning C4306:
'type cast' : conversion from 'int' to 'void *' of greater size
1[...]\libsofia-sip-ua\http\sofia-sip/http_header.h(243): warning C4306:
'type cast' : conversion from 'int' to 'msg_header_t *' of greater size


Any suggestions?

kind regards
Martin Staas
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3510029 ] sofia sip crash on android

[SourceForge . net]

Bugs item #3510029, was opened at 2012-03-22 03:14
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3510029group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: sofia sip crash on android

Initial Comment:
When the TO sip header or FROM sip header starts with a '', the code crash on 
android.   After tracking the problem it seems that there is an error in 
sip_basic.c. In the  method sip_name_addr you can see the variable is 
assigned to an empty string when the sip header starts with a ''.

 if (s[n] == '') {
  /* OK, we got a display name */
  display = s; s += n + 1;
  /* NUL terminate display name */
  while (n  0  IS_LWS(display[n - 1]))
n--;
  if (n  0)
display[n] = '\0';
  else
   display=;

Since the address of display is assigned to *return_display, this gives 
problems on Android.
If we change display= with display=NULL the code doesn't crashed.



   



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3510029group_id=143636

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] sofia sip crash on ARM processo

[Chris Herssens]

Hello All,

I found the error about why sofia sip crashed on android.
The problem is in sip_basic.c in the the method sip_name_addr_d. there
you can find:

if (n0)
  display[n] ='\0';
else
  display=;
...
if (return_display)
*return_display = display;


Now if n=0 then the address for return_display  is undefined. if I
replace display= with display=NULL, the incoming sip request works
fine.


regards,

Chris

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] sofia sip crash on ARM processor

[Chris Herssens]

Hello all,


I still have problems running sofia-sip on a ARM processor. Sometimes
on incoming SIP requests, sofia-sip crash when calling  tagi_t
*msghdrtag_dup(tagi_t *dst, tagi_t const *src, void **bb). To find
out what is going
wrong I put some logs and it seems that the variable size (= SIZE_MAX
- (uintptr_t)b) is always bigger than ISSIZE_MAX. The crash happens
since after calling the function b = hc-hc_dup_one(h, o, b, size),
b is not null.
Is it normal that size is always bigger than ISSIZE_MAX. Does someone
has the same problem on ARM  processor ? Maybe I need to add some
compile flags ?
I use sofia sip version 1.12.11


Regards,

Chris

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Patches-3496353 ] Fix Date header decoding on leap years

[SourceForge . net]

Patches item #3496353, was opened at 2012-03-02 10:55
Message generated for change (Tracker Item Submitted) made by bvallee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756078aid=3496353group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Benoît Vallée (bvallee)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix Date header decoding on leap years

Initial Comment:
There is an error in msg_date_d: 1 day is missing for the month of March on 
leap years.
On leap years, we need to add 1 day from March, not from April! (mon  1 
instead of mon  2 because month count start at 0)

Here is the patch.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756078aid=3496353group_id=143636

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-Sip for FreeBSD

[Michael Jerris]

It compiles and to my knowledge works fine on fbsd.

Mike

On Nov 13, 2011, at 3:16 PM, ogogon wrote:
 Why in the operating system FreeBSD is not present ported distributive 
 of Sofia-SIP?
 I formed the opinion that the Sofia-SIP - the most advanced and 
 supported by SIP stack.
 Sofia-SIP is not portable to FreeBSD?


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Sofia-Sip for FreeBSD

[ogogon]

Good evening!

Why in the operating system FreeBSD is not present ported distributive 
of Sofia-SIP?
I formed the opinion that the Sofia-SIP - the most advanced and 
supported by SIP stack.
Sofia-SIP is not portable to FreeBSD?

Ogogon.

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Sofia SIP for iPhone

[f.erfurth]

Hi,
I want to know if Sofia SIP is suitable for a project of an iPhone-App. Are
there iPhone developer here? Maybe some devel-docs for iPhone?

cu Floh
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Sofia-sip Firing nua_r_subscribe Event Instead of nua_r_unsubscribe Event

[Jerry Richards]

Has anyone noticed sofia-sip generating the nua_r_subscribe event instead of 
nua_r_unsubscribe event, after invoking nua_unsubscribe()?

Thanks,
Jerry
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-sip Firing nua_r_subscribe Event Instead of nua_r_unsubscribe Event

[Jerry Richards]

Actually, I think this was a glitch in a log capture, so this might be a 
non-issue.

From: Jerry Richards
Sent: Wednesday, September 28, 2011 3:57 PM
To: 'sofia-sip-devel@lists.sourceforge.net'
Subject: Sofia-sip Firing nua_r_subscribe Event Instead of nua_r_unsubscribe 
Event

Has anyone noticed sofia-sip generating the nua_r_subscribe event instead of 
nua_r_unsubscribe event, after invoking nua_unsubscribe()?

Thanks,
Jerry
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia-Sip Supported RTP Stack

[Pekka Pessi]

Hi,

2011/8/18 Meftah Tayeb tayeb.mef...@gmail.com:
 do sofia include a RTP stack ?
 how can i integrate existing RTP stack with Sofia ?

Please see sofsip-cli for an example of integrating a media stack with
Sofia SIP.

 and if RTP stack is integrated/supported, what codecs are supported ?
 can i inject aditional codecs to the existing RTP Stack ?

All the codecs that do not require any fancy SDP features are readily supported.

-- 
Pekka.Pessi mail at nokia.com

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Sofia-Sip Supported RTP Stack

[Meftah Tayeb]

hello,
do sofia include a RTP stack ?
how can i integrate existing RTP stack with Sofia ?
and if RTP stack is integrated/supported, what codecs are supported ?
can i inject aditional codecs to the existing RTP Stack ?
thank you.
Meftah Tayeb
IT Consulting
http://www.tmvoip.com/ 
phone: +21321656139
Mobile: +213661490005


__ Information provenant d'ESET NOD32 Antivirus, version de la base des 
signatures de virus 6388 (20110818) __

Le message a été vérifié par ESET NOD32 Antivirus.

http://www.eset.com

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3394305 ] subsequent incoming REGISTER requests fail

[SourceForge . net]

Bugs item #3394305, was opened at 2011-08-19 11:42
Message generated for change (Tracker Item Submitted) made by max4656
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3394305group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Maxim (max4656)
Assigned to: Nobody/Anonymous (nobody)
Summary: subsequent incoming REGISTER requests fail

Initial Comment:
I try to create a simple SIP server. Requests are processed asynchronously. 
Tests showed a problem with subsequent registers: first register is received 
and processed normally (200 ok was sent), after that I wait for re-register 
(and don't destroy hua_handle), it is received (with the same tags and call-id 
as the first one), but neither it is passed for processing, nor it is responded 
automatically.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3394305group_id=143636

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3353910 ] FTBFS: ./sofia-sip/sip_extra.h:2:1: error: expected identifi

[SourceForge.net]

Bugs item #3353910, was opened at 2011-07-04 20:27
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3353910group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Laurent Bigonville (bigon)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTBFS: ./sofia-sip/sip_extra.h:2:1: error: expected identifi

Initial Comment:
Hi,

sofia-sip FTBFS on debian and ubuntu with error like : 
./sofia-sip/sip_extra.h:2:1: error: expected identifier or '(' before '}' token

More information: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628247

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2011-07-14 16:20

Message:
sip_extra.h is a generated file; perhaps something goes wrong in the
processing script. Can you post the file as it is created in that build
environment?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3353910group_id=143636

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on Lean Startup 
Secrets Revealed. This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3353910 ] FTBFS: ./sofia-sip/sip_extra.h:2:1: error: expected identifi

[SourceForge.net]

Bugs item #3353910, was opened at 2011-07-04 19:27
Message generated for change (Tracker Item Submitted) made by bigon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3353910group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Laurent Bigonville (bigon)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTBFS: ./sofia-sip/sip_extra.h:2:1: error: expected identifi

Initial Comment:
Hi,

sofia-sip FTBFS on debian and ubuntu with error like : 
./sofia-sip/sip_extra.h:2:1: error: expected identifier or '(' before '}' token

More information: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628247

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3353910group_id=143636

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip SBC reference

[Michael Jerris]

Check out www.freeswitch.org.  It should already implement most of what your 
talking about.

Mike

On May 25, 2011, at 10:21 PM, Владимир Лучко wrote:

 Hello, everybody!
 I want to code SBC, using sofia-sip. Does has the project reference SBC (as, 
 for example opensipstack has OpenSBC)?
 Or may be there is some guide? My first try is not successeful. I create two 
 nua_t objects, set them NUTAG_URL with ip`s from the different networks. When 
 i got message on the first nua, i try to use SIPTAG_SIP (sip_t* obj) to 
 send it through the other nua. 
 
 Something like that:
 
 -
 /*NUA 1*/
 snprintf (bind_url, sizeof(bind_url), 
 sip:%s:5060;maddr=%s;transport=udp,tcp, IP1, IP1);
 trace_info (Bind SIP to %s\n, bind_url);
 g_nua1 = nua_create (g_root, sip_callback, NULL, NUTAG_URL (bind_url), 
 TAG_NULL ());
 ...
 nua_set_params (g_nua1, NUTAG_AUTOANSWER (0),  NUTAG_AUTOACK (0), 
 NUTAG_AUTO302 (0),
  NTATAG_PASS_100 (1), TAG_NULL ());
 
  snprintf (bind_url, sizeof(bind_url), 
 sip:%s:5060;maddr=%s;transport=udp,tcp, IP2, IP2);
  trace_info (Bind SIP to %s\n, bind_url);
  g_nua2 = nua_create (g_root, sip_callback, NULL, NUTAG_URL (bind_url), 
 NUTAG_AUTOANSWER (0),
   NUTAG_AUTOACK (0), NUTAG_AUTO302 (0), NTATAG_PASS_100 (1), TAG_NULL ());
  
 nua_set_params (g_nua2, NUTAG_AUTOANSWER (0), NUTAG_AUTOACK (0), 
 NUTAG_AUTO302 (0),
  NTATAG_PASS_100 (1), TAG_NULL ());
 
 
  static void
  sip_callback (nua_event_t event, int status, char const *phrase, nua_t * 
 nua, void * ctx_root,
  nua_handle_t * nh, void * ctx_handle, sip_t const *sip, tagi_t tags[])
  {
 ...
  nua_handle_t * nhn = nua_handle (g_nua2, NULL, TAG_NULL());
 ...
  nua_invite (nhn, SIPTAG_SIP(sip),TAG_NULL());
 }
 -
 
 Send invite to the nua1 ip and try to resend it into nua2. Got the error on 
 nua_invite:
 
 nua_stack.c:527: nua_signal: Assertion `b == bend' failed.
 
 Look into the stack code - does msgopbjtag_dup for duplicate sip tag work 
 wrong or is there other reason for that assertion?
 
 Thank you for answer.
 
 -- 
 Best regards, 
 Vladimir O. Luchko 
 Novosibirsk, Eltex
 E-mail: vlad.l...@mail.ru
 
 --
 vRanger cuts backup time in half-while increasing security.
 With the market-leading solution for virtual backup and recovery, 
 you get blazing-fast, flexible, and affordable data protection.
 Download your free trial now. 
 http://p.sf.net/sfu/quest-d2dcopy1___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] sofia-sip SBC reference

[Владимир Лучко]

Hello, everybody!
I want to code SBC, using sofia-sip. Does has the project reference SBC (as, 
for example opensipstack has OpenSBC)?
Or may be there is some guide? My first try is not successeful. I create two 
nua_t objects, set them NUTAG_URL with ip`s from the different networks. When i 
got message on the first nua, i try to use SIPTAG_SIP (sip_t* obj) to send it 
through the other nua. 

Something like that:

-
 /*NUA 1*/ 
snprintf (bind_url, sizeof(bind_url), sip:%s:5060;maddr=%s;transport=udp,tcp, 
IP1, IP1);
trace_info (Bind SIP to %s\n, bind_url);
g_nua1 = nua_create (g_root, sip_callback, NULL, NUTAG_URL (bind_url), TAG_NULL 
());
...
nua_set_params (g_nua1, NUTAG_AUTOANSWER (0),  NUTAG_AUTOACK (0), NUTAG_AUTO302 
(0),
     NTATAG_PASS_100 (1), TAG_NULL ());

 snprintf (bind_url, sizeof(bind_url), 
sip:%s:5060;maddr=%s;transport=udp,tcp, IP2, IP2);
 trace_info (Bind SIP to %s\n, bind_url);
 g_nua2 = nua_create (g_root, sip_callback, NULL, NUTAG_URL (bind_url), 
NUTAG_AUTOANSWER (0),
      NUTAG_AUTOACK (0), NUTAG_AUTO302 (0), NTATAG_PASS_100 (1), TAG_NULL ());
 
nua_set_params (g_nua2, NUTAG_AUTOANSWER (0), NUTAG_AUTOACK (0), NUTAG_AUTO302 
(0),
     NTATAG_PASS_100 (1), TAG_NULL ());


 static void
 sip_callback (nua_event_t event, int status, char const *phrase, nua_t * nua, 
void * ctx_root,
 nua_handle_t * nh, void * ctx_handle, sip_t const *sip, tagi_t tags[])
 {
...
     nua_handle_t * nhn = nua_handle (g_nua2, NULL, TAG_NULL());
...
     nua_invite (nhn, SIPTAG_SIP(sip),TAG_NULL());
}
-

Send invite to the nua1 ip and try to resend it into nua2. Got the error on 
nua_invite:

nua_stack.c:527: nua_signal: Assertion `b == bend' failed.

Look into the stack code - does msgopbjtag_dup for duplicate sip tag work wrong 
or is there other reason for that assertion?

Thank you for answer.

--
Best regards,
Vladimir O. Luchko
Novosibirsk, Eltex
E-mail: vlad.l...@mail.ru
--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Feature Requests-3306245 ] Use default certificate paths from OpenSSL

[SourceForge.net]

Feature Requests item #3306245, was opened at 2011-05-23 14:29
Message generated for change (Tracker Item Submitted) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756079aid=3306245group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use default certificate paths from OpenSSL

Initial Comment:
It should be possible to make OpenSSL use default paths to search CA 
certificates for verification.
A branch with a quick and dirty implementation is available here:
https://gitorious.org/~mzabaluev/sofia-sip/mzabaluev-sofia-sip/commits/system-ca-path

A backwards-compatible change would have to add a tag to enable this behavior, 
retaining the previous path use by default.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756079aid=3306245group_id=143636

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3291837 ] error of compile sofia sip client

[SourceForge.net]

Bugs item #3291837, was opened at 2011-04-23 06:39
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3291837group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: error of compile sofia sip client

Initial Comment:
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include/sofia-sip-1.12 
-I/usr/local/include/sofia-sip-1.12 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -g -O2 -MT ssc_sip.lo -MD -MP -MF .deps/ssc_sip.Tpo 
-c ssc_sip.c  -fPIC -DPIC -o .libs/ssc_sip.o
ssc_sip.c: In function 'ssc_i_state':
ssc_sip.c:1036: error: 'soatag_local_sdp_str_ref' undeclared (first use in this 
function)
ssc_sip.c:1036: error: (Each undeclared identifier is reported only once
-
sofia sip 1.12.11
sofia sip client 0.16

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3291837group_id=143636

--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3291837 ] error of compile sofia sip client

[SourceForge.net]

Bugs item #3291837, was opened at 2011-04-23 06:39
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3291837group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: error of compile sofia sip client

Initial Comment:
 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/include/sofia-sip-1.12 
-I/usr/local/include/sofia-sip-1.12 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -pthread -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -g -O2 -MT ssc_sip.lo -MD -MP -MF .deps/ssc_sip.Tpo 
-c ssc_sip.c  -fPIC -DPIC -o .libs/ssc_sip.o
ssc_sip.c: In function 'ssc_i_state':
ssc_sip.c:1036: error: 'soatag_local_sdp_str_ref' undeclared (first use in this 
function)
ssc_sip.c:1036: error: (Each undeclared identifier is reported only once
-
sofia sip 1.12.11
sofia sip client 0.16

--

Comment By: https://www.google.com/accounts ()
Date: 2011-04-23 08:19

Message:
This has been fixed in gitorious, please see
http://gitorious.org/sofia-sip/sofia-sip/commit/bcd0f17fd83f2dfe570a3ab17249a5c7290b27f2/

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3291837group_id=143636

--
Fulfilling the Lean Software Promise
Lean software platforms are now widely adopted and the benefits have been 
demonstrated beyond question. Learn why your peers are replacing JEE 
containers with lightweight application servers - and what you can gain 
from the move. http://p.sf.net/sfu/vmware-sfemails
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia sip stack 1.12.10 crashed in stateless mode

[kiran kumar]

Hi Pekka,

As you adviced I check the code,
1) I am locking the nta agent from starting to end.
Also i am no where destroying the irq more than once.

2) while creating the NTATAG_UA(0).
Coming to timeout fires, this may happen either for invite 200 or
non-invite 200.

3) The scenario is as follows,

I am sending the 200OK for invite then the irq should be moved to
completed queue.
But it is still persisting in porceeding queue and thereby failing the
assertion *queue-q_tail for newly coming transaction


(gdb) bt
#0  0x001be7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x002037a5 in raise () from /lib/tls/libc.so.6
#2  0x00205209 in abort () from /lib/tls/libc.so.6
#3  0x001fcd91 in __assert_fail () from /lib/tls/libc.so.6
#4  0x00c5db30 in incoming_create (agent=0x83f7b08, msg=0xa41d76e8,
sip=0xa41d7784, tport=0x83f84e0, tag=0x0) at nta.c:5049
#5  0x00c6d412 in leg_recv (leg=0x83f80c0, msg=0xa41d76e8, sip=0xa41d7784,
tport=0x83f84e0) at nta.c:4659
#6  0x00c6e83d in agent_recv_request (agent=0x83f7b08, msg=0xa41d76e8,
sip=0xa41d7784, tport=0x83f84e0) at nta.c:2955
#7  0x00c6efee in agent_recv_message (agent=0x83f7b08, tport=0x83f84e0,
msg=0xa41d76e8, tport_via=0x83f8a98, now=
  {tv_sec = 274877907, tv_usec = 75630}) at nta.c:2722
#8  0x00cc4984 in tport_base_deliver (self=0x0, msg=0xa41d76e8, now={tv_sec
= 3508559559, tv_usec = 75630}) at tport.c:3013
#9  0x00ccb031 in tport_deliver (self=0x83f84e0, msg=0xa41d76e8, next=0x0,
sc=0x0, now={tv_sec = 3508559559, tv_usec = 75630})
at tport.c:3002
#10 0x00ccb2ab in tport_parse (self=0x83f84e0, complete=1, now={tv_sec =
3508559559, tv_usec = 75630}) at tport.c:2919
#11 0x00ccb42d in tport_recv_event (self=0x83f84e0) at tport.c:2861
#12 0x00ccb6d1 in tport_base_wakeup (self=0x83f84e0, events=1) at
tport.c:2763
#13 0x00cbbdac in su_epoll_port_wait_events (self=0x83f7628, tout=81) at
su_epoll_port.c:506
#14 0x00cb9624 in su_base_port_run (self=0x83f7628) at su_base_port.c:342
#15 0x00cb5d75 in su_root_run (self=0x0) at su_port.h:310
#16 0x00cb9fee in su_pthread_port_clone_main (varg=0xbfef0130) at
su_pthread_port.c:321
#17 0x0042a371 in start_thread () from /lib/tls/libpthread.so.0
#18 0x002a3ffe in clone () from /lib/tls/libc.so.6


(gdb) p *queue-q_tail
$9 = (nta_incoming_t *) 0xa400de78

The highlited pointer is the one I am destroying before this assertion
failure happens, after receiving the ACK for that invite.

The same scenario was observed even i dont delete irq up to the time I
receive BYE for that call.

4) When i change the NTATAG_UA(1),
assertion is failing at irq-irq_status = 200 while timer H is
expiring.

Please help me how to come out of this problem.

Thanks,
Kiran.

On Sat, Mar 5, 2011 at 4:39 AM, Pekka Pessi ppe...@gmail.com wrote:

 Hi Kiran,

 2011/2/26 kiran kumar g.kiranredd...@gmail.com:
  In my application I am destroying the invite transaction (irq) after
  receiving ack for 200 OK,
  the ACK transaction (irq) immediately after receiving the ACK.
  And that of BYE transaction (irq) after sending 200 OK.
  I am using nta_incoming_destroy(irq) method to do the same.
  1) But while i was running the load, Sofia stack is getting crashed with
 the
  following assertion failure
  for a completely new request which may be invite or bye,
  (independent of the transaction for which i am destroying irq in the
  application).
   sipng: nta.c:5438: incoming_queue: Assertion `*queue-q_tail ==
 ((void
  *)0)' failed.
   Aborted (core dumped)
   And from the GDB findings I observed that
   *queue-q_tail points to the irq which i was destroying in my
  application.

 I think you end up destroying the same irq twice. Please doublecheck your
 code..

  2) From the api documentation it is clear that the destroyed irq should
 be
  in disposable state up to the timer expires.
   Please tell me when exactly this timer expires. (i.e., the default
  timer value )

 The non-INVITE irqs are destroyed once the timer J expires, the timer
 J duration is T1x64 (normally, 32 seconds). However, the irq can be
 destroyed earlier if

 1) if the NTA is not in UA mode or
 2) the response was sent via TCP or TLS

  3) Is there any way that i can put mutex locks in my application to avoid
  this synchronization problem.
  I am suspecting this behavior as bug in stack.

 You should protect whole nta_agent_t with a mutex, I'm afraid.

 --
 Pekka.Pessi mail at nokia.com

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net

[Sofia-sip-devel] sofia sip stack 1.12.10 crashed in stateless mode

[kiran kumar]

Dear Pekka Pessi,

I am using nta api for handling stateless transactions from sofia sip stack
1.12.10 in my application.

In my application I am destroying the invite transaction (irq) after
receiving ack for 200 OK,
the ACK transaction (irq) immediately after receiving the ACK.
And that of BYE transaction (irq) after sending 200 OK.

I am using nta_incoming_destroy(irq) method to do the same.

1) But while i was running the load, Sofia stack is getting crashed with the
following assertion failure
for a completely new request which may be invite or bye,
(independent of the transaction for which i am destroying irq in the
application).

 sipng: nta.c:5438: incoming_queue: Assertion `*queue-q_tail == ((void
*)0)' failed.
 Aborted (core dumped)

 And from the GDB findings I observed that

 *queue-q_tail points to the irq which i was destroying in my
application.

2) From the api documentation it is clear that the destroyed irq should be
in disposable state up to the timer expires.
 Please tell me when exactly this timer expires. (i.e., the default
timer value )

3) Is there any way that i can put mutex locks in my application to avoid
this synchronization problem.

I am suspecting this behavior as bug in stack.
Kindly let me know if any other information is required to solve this
problem.

Thanks in advance,

With Love,
Kiran.
--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Patches-3184900 ] support for 503 and SRV. RFC 3263

[SourceForge.net]

Patches item #3184900, was opened at 2011-02-17 15:39
Message generated for change (Tracker Item Submitted) made by adubovikov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756078aid=3184900group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandr Dubovikov (adubovikov)
Assigned to: Nobody/Anonymous (nobody)
Summary: support for 503 and SRV. RFC 3263

Initial Comment:
RFC 3263 
For SIP requests, failure occurs if the transaction layer reports a 503 error 
response or a transport failure of some sort (generally,
   due to fatal ICMP errors in UDP or connection failures in TCP).Failure 
also occurs if the transaction layer times out without ever
   having received any response, provisional or final (i.e., timer B or   timer 
F in RFC 3261 [1] fires).  If a failure occurs, the client
   SHOULD create a new request, which is identical to the previous ...

unfortanly, sofia try to retransmit method (for example REGISTER) to the same 
destination. The patch try to fix this problem.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756078aid=3184900group_id=143636

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [sofia-sip-devel] digest authorization using HA1 directly

[Pekka Pessi]

Hi Paulo,

2011/1/13 Paulo Vicentini vicentini.pa...@gmail.com:
 Attached is hack to use HA1 with sofia-sip
 Example:
 nua_authenticate(nh, SIPTAG_EXPIRES_STR(3600), NUTAG_AUTH(authentication),
 TAG_END())

 where authentication is string: Digest-HA1:realm:user:HA1

I did it in a more complex way, so you should have

HA1+Digest:realm:user:HA1+hash

For example

HA1+Digest:ims3.so.noklab.net:user1:HA1+c0890ff7a4fadc50c45f392ec4312965

-- 
Pekka.Pessi mail at nokia.com

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded

[SourceForge.net]

Bugs item #3146414, was opened at 2010-12-27 17:24
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 7
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expired contact entries are never discarded

Initial Comment:
As reported in:

https://bugs.maemo.org/show_bug.cgi?id=8615
https://bugs.freedesktop.org/show_bug.cgi?id=32615

When two sofia-sip stacks meet each other, one as the UA and the other as a 
proxy, they happily accumulate outdated Contact headers without end.

--

Comment By: SourceForge Robot (sf-robot)
Date: 2011-01-25 20:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

--

Comment By: Pekka Pessi (ppessi)
Date: 2011-01-10 22:34

Message:
Proposed fix merged to git.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-29 15:42

Message:
A fix is offered for review at
http://gitorious.org/sofia-sip/sofia-sip/merge_requests/4

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 19:46

Message:
Could be simple, though, in outbound_register_response:

  ob-ob_rcontact = sip_contact_dup(ob-ob_home,
request-sip_contact);

This is a copy of all contact headers present in the request. It then goes
on to populate any REGISTER request in the same dialog usage.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 19:02

Message:
Marking down a suspicious place where accumulation of headers may occur:

nua/nua_stack.c, line 629:  nua_stack_authenticate(nua, nh, event, tags);

The client request can be restarted with event tags added directly to
cr_msg in the client request structure. This is probably not the case where
the proxy sends us contact headers, though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3027352 ] Unable nua_destroy(), since nua_r_shutdown never arrives

[SourceForge.net]

Bugs item #3027352, was opened at 2010-07-09 14:55
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3027352group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Scorp (scorpfa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable nua_destroy(), since nua_r_shutdown never arrives

Initial Comment:
Following Code for shutting down UA and Root is not working, because  
nua_r_shutdown event never comes through the event handler.

nua_shutdown(m_nua);

// -- Here: endless waiting for nua_r_shutdown

su_root_break(getRoot());
nua_destroy(m_nua); // -- This would fail, since shutdown was not completed

Cheers

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2011-01-18 15:29

Message:
Do you use the glib mainloop integration?

There is a problem in either nua_shutdown or nua_destroy where the event
loop is iterated inside the function (which is a pretty daft idea), and
glib event source processing does not allow this by default.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3027352group_id=143636

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-2007672 ] IPv6 contact is used on IPv4 transport

[SourceForge.net]

Bugs item #2007672, was opened at 2008-07-01 15:38
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2007672group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: IPv6 contact is used on IPv4 transport

Initial Comment:
Copied from Telepathy-SofiaSIP bug # 1988988:

My client has both ipv4 and ipv6 addresses. It registers to a sip server
with only ipv4. In the telepathy debug output i see:

nta::contact: sip:sjoerd@[2a01:348:16d:0:20d:93ff:fe83:5a93]:44547

and on the server it says:
Contact user
sip:sjoerd@[2a01:348:16d:0:20d:93ff:fe83:5a93]:44547


--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2011-01-17 16:13

Message:
Duplicate of 1751089.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-29 18:14

Message:
There are some interesting race conditions when running tests on a
dual-stack host which seem to be related to this problem:

test_refer.c:502: check_sofia test_refer0() FAILED:
nua_event_name(e-data-e_event) != nua_event_name(nua_i_notify) or
nua_i_bye != nua_i_notify
75%: Checks: 8, Failures: 2, Errors: 0
suite_for_nua.c:114:F:with-proxy:with_proxy:0: Failure
'test_call_cancel(ctx)' occured
suite_for_nua.c:144:F:with-proxy-and-nat:with_proxy_and_nat:0: Failure
'test_refer(ctx)' occured

In the transport logs, I see the transport vs Via confusion:

  

send 440 bytes to udp/[127.0.0.1]:40531 at 16:07:04.984607:
  

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
[::1]:56324;rport=40531;branch=z9hG4bK889NQ3Uy3r82r;received=127.0.0.1
   From: sip:al...@example.com;tag=HZgg3tZKtX00r
   To: sip:b...@example.org;tag=NDHFpHcQ597DN
   Call-ID: 83ee296f-8e08-122e-bd84-00218696a9bc
   CSeq: 6483350 BYE
   User-Agent: sofia-sip/1.12.10devel
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE
   Supported: timer, 100rel
   Content-Length: 0


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2007672group_id=143636

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [sofia-sip-devel] digest authorization using HA1 directly

[Paulo Vicentini]

Attached is hack to use HA1 with sofia-sip

Example:
nua_authenticate(nh, SIPTAG_EXPIRES_STR(3600), NUTAG_AUTH(authentication),
TAG_END())

where authentication is string: Digest-HA1:realm:user:HA1

Paulo

On Tue, Jan 11, 2011 at 5:42 PM, Paulo Vicentini
vicentini.pa...@gmail.comwrote:

 Hi Pekka

 Thanks for commenting , I will give it a try.

 Regards
 Paulo

 On Mon, Jan 10, 2011 at 9:20 PM, Pekka Pessi ppe...@gmail.com wrote:

 Hi Paulo,

 2010/12/18 Paulo Vicentini vicentini.pa...@gmail.com:
  Thanks for your tips
  If It uses a Digest-HA1 scheme, it would need to receive the same from
 the
  registrar server (matching schemes). It would be good to be server
 agnostic
  (Digest)
  int ca_credentials(...
  ... ...
  if ((scheme != NULL  !su_casematch(scheme, ca-ca_scheme)) ||
  (realm != NULL  !su_strmatch(realm, ca-ca_realm)))
  return 0;
 
  It needs to somehow to ignore above code, maybe checking for
 Digest-HA1

 Yes, the ca_credentials should somehow magically match the
 Digest-HA1 with Digest, and somehow store the HA1 in the
 auth_client_t structure so that the digest algorithm itself would
 recognize the HA1. The current authentication client design does not
 support that very well.

 --
 Pekka.Pessi mail at nokia.com





ha1-sofia.patch
Description: Binary data
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [sofia-sip-devel] digest authorization using HA1 directly

[Paulo Vicentini]

Hi Pekka

Thanks for commenting , I will give it a try.

Regards
Paulo

On Mon, Jan 10, 2011 at 9:20 PM, Pekka Pessi ppe...@gmail.com wrote:

 Hi Paulo,

 2010/12/18 Paulo Vicentini vicentini.pa...@gmail.com:
  Thanks for your tips
  If It uses a Digest-HA1 scheme, it would need to receive the same from
 the
  registrar server (matching schemes). It would be good to be server
 agnostic
  (Digest)
  int ca_credentials(...
  ... ...
  if ((scheme != NULL  !su_casematch(scheme, ca-ca_scheme)) ||
  (realm != NULL  !su_strmatch(realm, ca-ca_realm)))
  return 0;
 
  It needs to somehow to ignore above code, maybe checking for Digest-HA1

 Yes, the ca_credentials should somehow magically match the
 Digest-HA1 with Digest, and somehow store the HA1 in the
 auth_client_t structure so that the digest algorithm itself would
 recognize the HA1. The current authentication client design does not
 support that very well.

 --
 Pekka.Pessi mail at nokia.com

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded

[SourceForge.net]

Bugs item #3146414, was opened at 2010-12-27 19:24
Message generated for change (Settings changed) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Pending
Resolution: Fixed
Priority: 7
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expired contact entries are never discarded

Initial Comment:
As reported in:

https://bugs.maemo.org/show_bug.cgi?id=8615
https://bugs.freedesktop.org/show_bug.cgi?id=32615

When two sofia-sip stacks meet each other, one as the UA and the other as a 
proxy, they happily accumulate outdated Contact headers without end.

--

Comment By: Pekka Pessi (ppessi)
Date: 2011-01-11 00:34

Message:
Proposed fix merged to git.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-29 17:42

Message:
A fix is offered for review at
http://gitorious.org/sofia-sip/sofia-sip/merge_requests/4

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 21:46

Message:
Could be simple, though, in outbound_register_response:

  ob-ob_rcontact = sip_contact_dup(ob-ob_home,
request-sip_contact);

This is a copy of all contact headers present in the request. It then goes
on to populate any REGISTER request in the same dialog usage.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 21:02

Message:
Marking down a suspicious place where accumulation of headers may occur:

nua/nua_stack.c, line 629:  nua_stack_authenticate(nua, nh, event, tags);

The client request can be restarted with event tags added directly to
cr_msg in the client request structure. This is probably not the case where
the proxy sends us contact headers, though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded

[SourceForge.net]

Bugs item #3146414, was opened at 2010-12-27 19:24
Message generated for change (Comment added) made by ppessi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 7
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expired contact entries are never discarded

Initial Comment:
As reported in:

https://bugs.maemo.org/show_bug.cgi?id=8615
https://bugs.freedesktop.org/show_bug.cgi?id=32615

When two sofia-sip stacks meet each other, one as the UA and the other as a 
proxy, they happily accumulate outdated Contact headers without end.

--

Comment By: Pekka Pessi (ppessi)
Date: 2011-01-11 00:34

Message:
Proposed fix merged to git.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-29 17:42

Message:
A fix is offered for review at
http://gitorious.org/sofia-sip/sofia-sip/merge_requests/4

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 21:46

Message:
Could be simple, though, in outbound_register_response:

  ob-ob_rcontact = sip_contact_dup(ob-ob_home,
request-sip_contact);

This is a copy of all contact headers present in the request. It then goes
on to populate any REGISTER request in the same dialog usage.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 21:02

Message:
Marking down a suspicious place where accumulation of headers may occur:

nua/nua_stack.c, line 629:  nua_stack_authenticate(nua, nh, event, tags);

The client request can be restarted with event tags added directly to
cr_msg in the client request structure. This is probably not the case where
the proxy sends us contact headers, though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [sofia-sip-devel] digest authorization using HA1 directly

[Pekka Pessi]

Hi Paulo,

2010/12/18 Paulo Vicentini vicentini.pa...@gmail.com:
 Thanks for your tips
 If It uses a Digest-HA1 scheme, it would need to receive the same from the
 registrar server (matching schemes). It would be good to be server agnostic
 (Digest)
 int ca_credentials(...
 ... ...
 if ((scheme != NULL  !su_casematch(scheme, ca-ca_scheme)) ||
 (realm != NULL  !su_strmatch(realm, ca-ca_realm)))
 return 0;

 It needs to somehow to ignore above code, maybe checking for Digest-HA1

Yes, the ca_credentials should somehow magically match the
Digest-HA1 with Digest, and somehow store the HA1 in the
auth_client_t structure so that the digest algorithm itself would
recognize the HA1. The current authentication client design does not
support that very well.

-- 
Pekka.Pessi mail at nokia.com

--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass

[SourceForge.net]

Bugs item #3034730, was opened at 2010-07-26 18:02
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3034730group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build system
Group: None
Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Pacho Ramos (pacho2)
Assigned to: Nobody/Anonymous (nobody)
Summary: torture_url test fail to pass

Initial Comment:
This has been noticed downstream:
http://bugs.gentoo.org/show_bug.cgi?id=328733#c2

PASS: run_test_sdp
==
All 2 tests passed
==
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
Making check in url
make[2]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-am
make[3]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  torture_url
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. 
-I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt 
-I./../su -I../su   -Wall -O2 -march=native -pipe -fomit-frame-pointer 
-ggdb -MT torture_url.o -MD -MP -MF .deps/torture_url.Tpo -c -o torture_url.o 
torture_url.c; \
then mv -f .deps/torture_url.Tpo .deps/torture_url.Po; else rm -f 
.deps/torture_url.Tpo; exit 1; fi
/bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 
-march=native -pipe -fomit-frame-pointer -ggdb  -Wl,-O1 -Wl,--as-needed -o 
torture_url  torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la 
../su/libsu.la -lssl -lcrypto -lrt -lpthread 
i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb 
-Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o  ./.libs/liburl.a 
../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto 
-lrt -lpthread  
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-TESTS
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
torture_url.c:279: torture_url test_sip() FAILED: 
url_query_as_header_string(home, url-url_headers) != \n\nCANNED MSG or NULL 
!= 

CANNED MSG
FAIL: torture_url
===
1 of 1 tests failed
===
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[2]: *** [check] Error 2
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua'
make: *** [check-recursive] Error 1

And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6

Thanks a lot for solving this

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2011-01-05 18:41

Message:
The fix is merged into master.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-29 20:12

Message:
A fix is available for review:

http://gitorious.org/sofia-sip/sofia-sip/merge_requests/3

--

Comment By: Pacho Ramos (pacho2)
Date: 2010-09-03 13:24

Message:
Yes, of course


$ gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --disable-nls
--with-system-zlib --disable-checking --disable-werror --enable-secureplt

[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass

[SourceForge.net]

Bugs item #3034730, was opened at 2010-07-26 17:02
Message generated for change (Comment added) made by pacho2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3034730group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build system
Group: None
Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Pacho Ramos (pacho2)
Assigned to: Nobody/Anonymous (nobody)
Summary: torture_url test fail to pass

Initial Comment:
This has been noticed downstream:
http://bugs.gentoo.org/show_bug.cgi?id=328733#c2

PASS: run_test_sdp
==
All 2 tests passed
==
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
Making check in url
make[2]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-am
make[3]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  torture_url
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. 
-I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt 
-I./../su -I../su   -Wall -O2 -march=native -pipe -fomit-frame-pointer 
-ggdb -MT torture_url.o -MD -MP -MF .deps/torture_url.Tpo -c -o torture_url.o 
torture_url.c; \
then mv -f .deps/torture_url.Tpo .deps/torture_url.Po; else rm -f 
.deps/torture_url.Tpo; exit 1; fi
/bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 
-march=native -pipe -fomit-frame-pointer -ggdb  -Wl,-O1 -Wl,--as-needed -o 
torture_url  torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la 
../su/libsu.la -lssl -lcrypto -lrt -lpthread 
i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb 
-Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o  ./.libs/liburl.a 
../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto 
-lrt -lpthread  
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-TESTS
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
torture_url.c:279: torture_url test_sip() FAILED: 
url_query_as_header_string(home, url-url_headers) != \n\nCANNED MSG or NULL 
!= 

CANNED MSG
FAIL: torture_url
===
1 of 1 tests failed
===
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[2]: *** [check] Error 2
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua'
make: *** [check-recursive] Error 1

And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6

Thanks a lot for solving this

--

Comment By: Pacho Ramos (pacho2)
Date: 2011-01-05 20:47

Message:
Thanks

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2011-01-05 17:41

Message:
The fix is merged into master.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-29 19:12

Message:
A fix is available for review:

http://gitorious.org/sofia-sip/sofia-sip/merge_requests/3

--

Comment By: Pacho Ramos (pacho2)
Date: 2010-09-03 12:24

Message:
Yes, of course


$ gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu 

[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded

[SourceForge.net]

Bugs item #3146414, was opened at 2010-12-27 19:24
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expired contact entries are never discarded

Initial Comment:
As reported in:

https://bugs.maemo.org/show_bug.cgi?id=8615
https://bugs.freedesktop.org/show_bug.cgi?id=32615

When two sofia-sip stacks meet each other, one as the UA and the other as a 
proxy, they happily accumulate outdated Contact headers without end.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-29 17:42

Message:
A fix is offered for review at
http://gitorious.org/sofia-sip/sofia-sip/merge_requests/4

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 21:46

Message:
Could be simple, though, in outbound_register_response:

  ob-ob_rcontact = sip_contact_dup(ob-ob_home,
request-sip_contact);

This is a copy of all contact headers present in the request. It then goes
on to populate any REGISTER request in the same dialog usage.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 21:02

Message:
Marking down a suspicious place where accumulation of headers may occur:

nua/nua_stack.c, line 629:  nua_stack_authenticate(nua, nh, event, tags);

The client request can be restarted with event tags added directly to
cr_msg in the client request structure. This is probably not the case where
the proxy sends us contact headers, though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-2007672 ] IPv6 contact is used on IPv4 transport

[SourceForge.net]

Bugs item #2007672, was opened at 2008-07-01 15:38
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2007672group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: IPv6 contact is used on IPv4 transport

Initial Comment:
Copied from Telepathy-SofiaSIP bug # 1988988:

My client has both ipv4 and ipv6 addresses. It registers to a sip server
with only ipv4. In the telepathy debug output i see:

nta::contact: sip:sjo...@[2a01:348:16d:0:20d:93ff:fe83:5a93]:44547

and on the server it says:
Contact user
sip:sjo...@[2a01:348:16d:0:20d:93ff:fe83:5a93]:44547


--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-29 18:14

Message:
There are some interesting race conditions when running tests on a
dual-stack host which seem to be related to this problem:

test_refer.c:502: check_sofia test_refer0() FAILED:
nua_event_name(e-data-e_event) != nua_event_name(nua_i_notify) or
nua_i_bye != nua_i_notify
75%: Checks: 8, Failures: 2, Errors: 0
suite_for_nua.c:114:F:with-proxy:with_proxy:0: Failure
'test_call_cancel(ctx)' occured
suite_for_nua.c:144:F:with-proxy-and-nat:with_proxy_and_nat:0: Failure
'test_refer(ctx)' occured

In the transport logs, I see the transport vs Via confusion:

  

send 440 bytes to udp/[127.0.0.1]:40531 at 16:07:04.984607:
  

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
[::1]:56324;rport=40531;branch=z9hG4bK889NQ3Uy3r82r;received=127.0.0.1
   From: sip:al...@example.com;tag=HZgg3tZKtX00r
   To: sip:b...@example.org;tag=NDHFpHcQ597DN
   Call-ID: 83ee296f-8e08-122e-bd84-00218696a9bc
   CSeq: 6483350 BYE
   User-Agent: sofia-sip/1.12.10devel
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE
   Supported: timer, 100rel
   Content-Length: 0


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2007672group_id=143636

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded

[SourceForge.net]

Bugs item #3146414, was opened at 2010-12-27 19:24
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expired contact entries are never discarded

Initial Comment:
As reported in:

https://bugs.maemo.org/show_bug.cgi?id=8615
https://bugs.freedesktop.org/show_bug.cgi?id=32615

When two sofia-sip stacks meet each other, one as the UA and the other as a 
proxy, they happily accumulate outdated Contact headers without end.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 21:46

Message:
Could be simple, though, in outbound_register_response:

  ob-ob_rcontact = sip_contact_dup(ob-ob_home,
request-sip_contact);

This is a copy of all contact headers present in the request. It then goes
on to populate any REGISTER request in the same dialog usage.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-28 21:02

Message:
Marking down a suspicious place where accumulation of headers may occur:

nua/nua_stack.c, line 629:  nua_stack_authenticate(nua, nh, event, tags);

The client request can be restarted with event tags added directly to
cr_msg in the client request structure. This is probably not the case where
the proxy sends us contact headers, though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-2531152 ] Does not cache some DNS results

[SourceForge.net]

Bugs item #2531152, was opened at 2009-01-23 16:16
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2531152group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Pekka Pessi (ppessi)
Summary: Does not cache some DNS results

Initial Comment:
In some circumstances, Sofia-SIP keeps requesting DNS records over and over 
again with every SIP request. See the attached log. Note also how NAPTR is 
requested repeatedly, even though nothing useful is obtained from the responses.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-27 19:20

Message:
Fixed in commit 01baa987b3bdc2791118c1be9b74b625f76d6b1c

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-03-03 16:58

Message:
The CNAME problem with proxy01.sipphone.com is still there with the recent
trunk changes.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-02-04 20:34

Message:
It breaks with proxy01.sipphone.com, too.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-02-04 20:05

Message:
The patch regresses a case where SRV refers to a CNAME. Granted it's not
allowed by strict DNS spec, but it used to work.

telepathy-sofiasip[2040]: nta: for sip1.cosmicparrot.net query
_sip._udp.sip1.cosmicparrot.net SRV
telepathy-sofiasip[2040]: nta: _sip._udp.sip1.cosmicparrot.net IN SRV 0 0 
5063 sip1.cosmicparrot.net. (udp)
telepathy-sofiasip[2040]: nta: for sip1.cosmicparrot.net query
sip1.cosmicparrot.net. A (cached)
telepathy-sofiasip[2040]: nta: for sip1.cosmicparrot.net query
_sip._tcp.sip1.cosmicparrot.net SRV
telepathy-sofiasip[2040]: nta: _sip._tcp.sip1.cosmicparrot.net IN SRV 0 0 
5062 sip1.cosmicparrot.net. (tcp)
telepathy-sofiasip[2040]: nta: for sip1.cosmicparrot.net query
sip1.cosmicparrot.net. A (cached)
telepathy-sofiasip[2040]: nta: for sip1.cosmicparrot.net query
sip1.cosmicparrot.net A (cached)
telepathy-sofiasip[2040]: GLIB DEBUG default -
tpsip_connection_sofia_callback: event nua_r_register: 503 DNS Error

;; QUESTION SECTION:
;sip1.cosmicparrot.net. IN  A

;; ANSWER SECTION:
sip1.cosmicparrot.net.  86400   IN  CNAME   svc.cosmicparrot.net.
svc.cosmicparrot.net.   49472   IN  A   217.152.255.16


--

Comment By: Pekka Pessi (ppessi)
Date: 2009-01-23 19:17

Message:
Fri Jan 23 19:13:41 EET 2009  Pekka Pessi first.l...@nokia.com
  * sresolv: caching SRES_RECORD_ERR in case a CNAME is returned, too
  
  Tracing the CNAMEs when doing cache lookups.

Misha, please verify.

--

Comment By: Pekka Pessi (ppessi)
Date: 2009-01-23 18:18

Message:
Looks like sres does not check that it got what it asked. 

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2531152group_id=143636

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded

[SourceForge.net]

Bugs item #3146414, was opened at 2010-12-27 19:24
Message generated for change (Tracker Item Submitted) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expired contact entries are never discarded

Initial Comment:
As reported in:

https://bugs.maemo.org/show_bug.cgi?id=8615
https://bugs.freedesktop.org/show_bug.cgi?id=32615

When two sofia-sip stacks meet each other, one as the UA and the other as a 
proxy, they happily accumulate outdated Contact headers without end.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3146414 ] Expired contact entries are never discarded

[SourceForge.net]

Bugs item #3146414, was opened at 2010-12-27 19:24
Message generated for change (Settings changed) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expired contact entries are never discarded

Initial Comment:
As reported in:

https://bugs.maemo.org/show_bug.cgi?id=8615
https://bugs.freedesktop.org/show_bug.cgi?id=32615

When two sofia-sip stacks meet each other, one as the UA and the other as a 
proxy, they happily accumulate outdated Contact headers without end.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3146414group_id=143636

--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [sofia-sip-devel] digest authorization using HA1 directly

[Paulo Vicentini]

Hi Pekka

Thanks for your tips
If It uses a Digest-HA1 scheme, it would need to receive the same from the
registrar server (matching schemes). It would be good to be server agnostic
(Digest)

int ca_credentials(...
... ...
if ((scheme != NULL  !su_casematch(scheme, ca-ca_scheme)) ||
(realm != NULL  !su_strmatch(realm, ca-ca_realm)))
return 0;

It needs to somehow to ignore above code, maybe checking for Digest-HA1


Regards
Paulo


On Wed, Dec 15, 2010 at 2:46 PM, Pekka Pessi ppe...@gmail.com wrote:

 Hi Paulo,

 2010/12/15 Paulo Vicentini vicentini.pa...@gmail.com:
  I using sofia-SIP as an UAC to register with a SIP registrar
  I'd like to avoid using the secret (it is indeed not available) directly
  while creating a digest authorization header with:
  int auc_digest_authorization(auth_client_t *ca,
  su_home_t *home,
  char const *method,
  url_t const *url,
  msg_payload_t const *body,
  msg_header_t **return_headers)
 
  Only HA1 = md5(username:realm:password) is available
  So that I intend to use HA1 = md5(username:realm:password) instead
  What do you say about that?

 It is doable with some modifications to iptsec/auth_client.c. You
 could modify the ca_credentials to store only the HA1 in the
 ca_client_t structure instead of the password (in case of Digest) and
 add a special scheme, e.g., Digest-HA1 where the password would
 contain the HA1.

 Patches are welcome.

 --
 Pekka.Pessi mail at nokia.com

--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [sofia-sip-devel] digest authorization using HA1 directly

[Pekka Pessi]

Hi Paulo,

2010/12/15 Paulo Vicentini vicentini.pa...@gmail.com:
 I using sofia-SIP as an UAC to register with a SIP registrar
 I'd like to avoid using the secret (it is indeed not available) directly
 while creating a digest authorization header with:
 int auc_digest_authorization(auth_client_t *ca,
 su_home_t *home,
 char const *method,
 url_t const *url,
 msg_payload_t const *body,
 msg_header_t **return_headers)

 Only HA1 = md5(username:realm:password) is available
 So that I intend to use HA1 = md5(username:realm:password) instead
 What do you say about that?

It is doable with some modifications to iptsec/auth_client.c. You
could modify the ca_credentials to store only the HA1 in the
ca_client_t structure instead of the password (in case of Digest) and
add a special scheme, e.g., Digest-HA1 where the password would
contain the HA1.

Patches are welcome.

-- 
Pekka.Pessi mail at nokia.com

--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [sofia-sip-devel] digest authorization using HA1 directly

[Paulo Vicentini]

Hi
I using sofia-SIP as an UAC to register with a SIP registrar
I'd like to avoid using the secret (it is indeed not available) directly
while creating a digest authorization header with:
int auc_digest_authorization(auth_client_t *ca,
su_home_t *home,
char const *method,
url_t const *url,
msg_payload_t const *body,
msg_header_t **return_headers)

Only HA1 = md5(username:realm:password) is available
So that I intend to use HA1 = md5(username:realm:password) instead

What do you say about that?

Thanks

Paulo
--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-1633969 ] nua stack timer runs too frequently

[SourceForge.net]

Bugs item #1633969, was opened at 2007-01-12 13:04
Message generated for change (Comment added) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=1633969group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Kai Vehmanen (kaiv)
Assigned to: Pekka Pessi (ppessi)
Summary: nua stack timer runs too frequently

Initial Comment:
The nua stack timer runs current at 1Hz. This is too frequent for some uses, so 
either the timer interval should be decreased, it should be made configurable, 
or completely replaced by more fine-grained timers (as was done in sresolv).


--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2010-12-07 11:43

Message:
This has been fixed by making the timers deferrable. Now the timers can use
a pacemaker on platforms where battery life matters.
I'm lost in this new interface, it seems I cannot close this bug myself.

--

Comment By: Pekka Pessi (ppessi)
Date: 2007-01-23 18:53

Message:
Logged In: YES 
user_id=52043
Originator: NO

The nta timer run at 16 Hz by default, too.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=1633969group_id=143636

--
What happens now with your Lotus Notes apps - do you make another costly 
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus 
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [Sofia-SIP-devel] RFC2833

[jonathan augenstine]

I am having some issues with setting RFC2833 in the SDP of an INVITE.  It is
not being set correctly so the remote server is responding with default
inband.  Can someone provide an example on how to correctly set the RFC2833
in the SDP?

Thank you.

Jonathan
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] [Sofia-SIP-devel] RFC2833

[jonathan augenstine]

I have resolved this issue.

On Tue, Oct 19, 2010 at 1:27 PM, jonathan augenstine
jaugenst...@gmail.comwrote:

 I am having some issues with setting RFC2833 in the SDP of an INVITE.  It
 is not being set correctly so the remote server is responding with default
 inband.  Can someone provide an example on how to correctly set the RFC2833
 in the SDP?

 Thank you.

 Jonathan

--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly 
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3065356 ] More robust behavior with pbxes.org (SCTP)

[SourceForge.net]

Bugs item #3065356, was opened at 2010-09-13 17:29
Message generated for change (Comment added) made by ppessi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3065356group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Pending
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: More robust behavior with pbxes.org (SCTP)

Initial Comment:
Originally reported in https://bugs.freedesktop.org/show_bug.cgi?id=30164

The stack is somehow tricked into using SCTP which is not supported by the 
kernel, and this makes a request fail.
There should be a fallback for this, unless there is some DNS misconfiguration 
on behalf of pbxes.org. I could not find any, except them responding to any A 
query with an IP address.

--

Comment By: Pekka Pessi (ppessi)
Date: 2010-09-17 19:05

Message:
The pbxes.org seems to have removed NAPTR and/or _sip._sctp. record.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3065356group_id=143636

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3065356 ] More robust behavior with pbxes.org (SCTP)

[SourceForge.net]

Bugs item #3065356, was opened at 2010-09-13 17:29
Message generated for change (Tracker Item Submitted) made by mzabaluev
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3065356group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mikhail Zabaluev (mzabaluev)
Assigned to: Nobody/Anonymous (nobody)
Summary: More robust behavior with pbxes.org (SCTP)

Initial Comment:
Originally reported in https://bugs.freedesktop.org/show_bug.cgi?id=30164

The stack is somehow tricked into using SCTP which is not supported by the 
kernel, and this makes a request fail.
There should be a fallback for this, unless there is some DNS misconfiguration 
on behalf of pbxes.org. I could not find any, except them responding to any A 
query with an IP address.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3065356group_id=143636

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass

[SourceForge.net]

Bugs item #3034730, was opened at 2010-07-26 17:02
Message generated for change (Comment added) made by pacho2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3034730group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build system
Group: None
Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Pacho Ramos (pacho2)
Assigned to: Nobody/Anonymous (nobody)
Summary: torture_url test fail to pass

Initial Comment:
This has been noticed downstream:
http://bugs.gentoo.org/show_bug.cgi?id=328733#c2

PASS: run_test_sdp
==
All 2 tests passed
==
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
Making check in url
make[2]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-am
make[3]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  torture_url
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. 
-I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt 
-I./../su -I../su   -Wall -O2 -march=native -pipe -fomit-frame-pointer 
-ggdb -MT torture_url.o -MD -MP -MF .deps/torture_url.Tpo -c -o torture_url.o 
torture_url.c; \
then mv -f .deps/torture_url.Tpo .deps/torture_url.Po; else rm -f 
.deps/torture_url.Tpo; exit 1; fi
/bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 
-march=native -pipe -fomit-frame-pointer -ggdb  -Wl,-O1 -Wl,--as-needed -o 
torture_url  torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la 
../su/libsu.la -lssl -lcrypto -lrt -lpthread 
i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb 
-Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o  ./.libs/liburl.a 
../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto 
-lrt -lpthread  
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-TESTS
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
torture_url.c:279: torture_url test_sip() FAILED: 
url_query_as_header_string(home, url-url_headers) != \n\nCANNED MSG or NULL 
!= 

CANNED MSG
FAIL: torture_url
===
1 of 1 tests failed
===
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[2]: *** [check] Error 2
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua'
make: *** [check-recursive] Error 1

And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6

Thanks a lot for solving this

--

Comment By: Pacho Ramos (pacho2)
Date: 2010-09-03 12:24

Message:
Yes, of course


$ gcc -v
Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --disable-nls
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.4.3/python
--enable-java-awt=gtk --enable-languages=c,c++,java,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3-r2
p1.2'
Thread model: posix
gcc version 4.4.3 (Gentoo 4.4.3-r2 

[Sofia-sip-devel] Sofia sip RFC2543

[Tech Micron]

Hi everyone,

I have a SIP device that is working with RFC 2543. I  am trying to send call 
using Sofia-SIP (via FreeSwitch), but none of my calls are going  through.
I have traced the debug on SOFIA and it returned an error as below. Can anyone 
help me to solve the problem? any hints?


recv 660 bytes from udp/[66.220.15.230]:5060 at 18:45:21.239029:
   
   INVITE sip:1...@66.220.15.234 SIP/2.0
   v: SIP/2.0/UDP 66.220.15.230
   To: sip:1...@66.220.15.234 sip:1...@66.220.15.234
   From: john odu 
sip:26679...@66.220.15.230;tag=4c5c58410003ac2076f6302c11fc3b7b
   i: 41585c4c2ba3030035e697f0a586d...@66.220.15.230
   CSeq: 1  INVITE
   m: john odu sip:26679...@66.220.15.230
   Supported: com.lilo.conferencing, com.lilo.mux
   User-Agent: liloSipMCU/3.1.6.200801281402
   c: application/sdp
   l: 212
   
   v=0
   o=mcu 0 0 IN IP4 66.220.15.230
   s=sip:26679...@66.220.15.230
   c=IN IP4 66.220.15.230
   t=0 0
   m=audio 2006 RTP/AVP 0 111
   a=ptime:20
   a=rtpmap:0 PCMU/8000
   a=rtpmap:111 telephone-event/8000
   a=xlilossrc:8
   
tport_deliver(0x97a1fb0): msg 0xb762bef8 (660 bytes) from 
udp/66.220.15.230:5060/sip next=(nil)
nta: received INVITE sip:1...@66.220.15.234 SIP/2.0 (CSeq 1)
nta: INVITE has bad To  header
nta: INVITE (1) is Bad To Header
tport_tsend(0x97a1fb0) tpn = UDP/66.220.15.230:5060
tport_resolve addrinfo = 66.220.15.230:5060
tport_by_addrinfo(0x97a1fb0): not found by name UDP/66.220.15.230:5060
tport_vsend(0x97a1fb0): 239 bytes of 239 to udp/66.220.15.230:5060
tport_vsend returned 239
send 239 bytes to udp/[66.220.15.230]:5060 at 18:45:21.239369:
   
   SIP/2.0 400 Bad To Header
   Via: SIP/2.0/UDP 66.220.15.230
   From: john odu 
sip:26679...@66.220.15.230;tag=4c5c58410003ac2076f6302c11fc3b7b
   Call-ID: 41585c4c2ba3030035e697f0a586d...@66.220.15.230
   CSeq: 1 INVITE
   Content-Length: 0



  --
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia sip RFC2543

[Fabio Margarido]

On Mon, Aug 16, 2010 at 13:45, Tech Micron techmicron...@yahoo.com wrote:
 I have traced the debug on SOFIA and it returned an error as below. Can 
 anyone help me to solve the problem? any hints?

Hi there,
If I remember correctly, '@' and ':' are not valid character in the
display-name portion of the header. Change it to something like To:
Name sip:1...@66.220.15.234 and it should work.
Regards.

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] Sofia sip RFC2543

[Michael Jerris]

Looks like this is due to missing quotes around the display name.

Mike

On Aug 16, 2010, at 12:45 PM, Tech Micron wrote:

 Hi everyone,
 
 I have a SIP device that is working with RFC 2543. I am trying to send call 
 using Sofia-SIP (via FreeSwitch), but none of my calls are going through.
 I have traced the debug on SOFIA and it returned an error as below. Can 
 anyone help me to solve the problem? any hints?
 
 
 recv 660 bytes from udp/[66.220.15.230]:5060 at 18:45:21.239029:

INVITE sip:1...@66.220.15.234 SIP/2.0
v: SIP/2.0/UDP 66.220.15.230
To: sip:1...@66.220.15.234 sip:1...@66.220.15.234
From: john odu 
 sip:26679...@66.220.15.230;tag=4c5c58410003ac2076f6302c11fc3b7b
i: 41585c4c2ba3030035e697f0a586d...@66.220.15.230
CSeq: 1 INVITE
m: john odu sip:26679...@66.220.15.230
Supported: com.lilo.conferencing, com.lilo.mux
User-Agent: liloSipMCU/3.1.6.200801281402
c: application/sdp
l: 212

v=0
o=mcu 0 0 IN IP4 66.220.15.230
s=sip:26679...@66.220.15.230
c=IN IP4 66.220.15.230
t=0 0
m=audio 2006 RTP/AVP 0 111
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:111 telephone-event/8000
a=xlilossrc:8

 tport_deliver(0x97a1fb0): msg 0xb762bef8 (660 bytes) from 
 udp/66.220.15.230:5060/sip next=(nil)
 nta: received INVITE sip:1...@66.220.15.234 SIP/2.0 (CSeq 1)
 nta: INVITE has bad To header
 nta: INVITE (1) is Bad To Header
 tport_tsend(0x97a1fb0) tpn = UDP/66.220.15.230:5060
 tport_resolve addrinfo = 66.220.15.230:5060
 tport_by_addrinfo(0x97a1fb0): not found by name UDP/66.220.15.230:5060
 tport_vsend(0x97a1fb0): 239 bytes of 239 to udp/66.220.15.230:5060
 tport_vsend returned 239
 send 239 bytes to udp/[66.220.15.230]:5060 at 18:45:21.239369:

SIP/2.0 400 Bad To Header
Via: SIP/2.0/UDP 66.220.15.230
From: john odu 
 sip:26679...@66.220.15.230;tag=4c5c58410003ac2076f6302c11fc3b7b
Call-ID: 41585c4c2ba3030035e697f0a586d...@66.220.15.230
CSeq: 1 INVITE
Content-Length: 0
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[Pekka Pessi]

Hi Gaurac,

2010/8/13 Pekka Pessi ppe...@gmail.com:
 2010/8/11 Gaurav Srivastva gaurav...@yahoo.com:
 The Via headers on Linux are sent correctly if TPORT_LOG is not defined. If 
 I define this variable then the problem starts happening.

 Oh my. Thanks for digging this out.

I've pushed the fix to gitorious, please test.

-- 
Pekka.Pessi mail at nokia.com

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[Gaurav Srivastva]

Hi,

Would highly appreciate if someone can tell me if this issue is resolved in 
sofia-sip stack or not.

Thanks


On Aug 8, 2010, at 2:49 AM, Gaurav Srivastva wrote:

 Hi,
 
 The notify request to the subscription is being responded to by Sofia-Sip 
 stack with one Via header from the SIP request missing.
 
 In the NOTIFY, the Via header is,
 
Via: SIP/2.0/UDP 
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP/2.0/UDP
  172.16.14.209:6015;branch=z9hG4bK86266194643563
 
 In the 200 OK response, the Via header being sent is,
 
Via: SIP/2.0/UDP 
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;received=172.16.14.209
 
 I'm using nua to send the subscribe request.
 
   handle = nua_handle(appl-nua,
   NULL, 
   SIPTAG_FROM(from_header),
   SIPTAG_TO(to_header),
   SIPTAG_ROUTE(route_header),
   SIPTAG_CONTACT(contact_header), 
   TAG_END());
   
   if(handle)
   {
 nua_subscribe(handle, 
   SIPTAG_EXPIRES_STR(3600),
   SIPTAG_EVENT_STR(presence),
   SIPTAG_ACCEPT_STR(application/pidf+xml),
   TAG_END());
 
   }
 
 The platform is OSX and xcode IDE.
 
 Can someone tell me what I'm doing wrong or is this a bug in sofia-sip stack?
 
 Thanks
 Gaurav
 --
 This SF.net email is sponsored by 
 
 Make an app they can't live without
 Enter the BlackBerry Developer Challenge
 http://p.sf.net/sfu/RIM-dev2dev 
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[Gaurav Srivastva]

Thanks for the update. Following is the log from the application showing the 
problem (check the Via in 200 OK).

Another issue I'm seeing is that the User-Agent headr in 200 OK response is 
different from the one in the SUBSCRIBE message.

recv 1559 bytes from udp/[172.16.4.161]:5060 at 20:49:02.635526:
   
   NOTIFY sip:mamah...@172.16.11.242:5060;transport=udp SIP/2.0
   Via: SIP/2.0/UDP 
acs-core1.intl.com:5060;branch=z9hG4bKd550206f22aacf124787628c15a9cc50.1,SIP/2.0/UDP
 
172.16.4.161:6015;branch=z9hG4bK1854423756626772
   Max-Forwards: 69
   From: sip:mamah...@node99.acs-core1.intl.com;tag=401559811623600
   To: sip:mamah...@node99.acs-core1.intl.com:5060;tag=503Ny97jjQH5S
   Call-ID: 8c98c482-1f63-122e-129a-000bdbd50d90
   CSeq: 2 NOTIFY
   Content-Type: application/pidf+xml
   Event: presence.account;x-intl-include=im-telephony-account-hotdesk
   Subscription-State: active
   Contact: 
sip:b544219e-1dd1-11b2-8fc7-b23336626566+b5442...@172.16.4.161:6015;transport=udp
   Content-Length: 862


tport_deliver(0x9242378): msg 0x9248778 (1559 bytes) from 
udp/172.16.4.161:5060/sip next=(nil)
nta: received NOTIFY sip:mamah...@172.16.11.242:5060;transport=udp SIP/2.0 
(CSeq 2)
nta: Via check: received=172.16.4.161
nta: canonizing sip:mamah...@172.16.11.242:5060 with contact
nta: NOTIFY (2) going to existing leg
nua: nua_stack_process_request: entering
nua(0x9243658): nua_notify_server_preprocess: active ()
nua: nua_application_event: entering
tport_tsend(0x9242378) tpn = UDP/172.16.4.161:5060
tport_resolve addrinfo = 172.16.4.161:5060
tport_by_addrinfo(0x9242378): not found by name UDP/172.16.4.161:5060
tport_vsend returned 558
send 558 bytes to udp/[172.16.4.161]:5060 at 20:49:02.636002:
   
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 
acs-core1.intl.com:5060;branch=z9hG4bKd550206f22aacf124787628c15a9cc50.1;received=172.16.4.161
   From: sip:mamah...@node99.acs-core1.intl.com;tag=401559811623600
   To: sip:mamah...@node99.acs-core1.intl.com:5060;tag=503Ny97jjQH5S
   Call-ID: 8c98c482-1f63-122e-129a-000bdbd50d90
   CSeq: 2 NOTIFY
   Contact: sip:mamah...@172.16.11.242:5060
   User-Agent: sofia-sip/1.12.10
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, 
NOTIFY, REFER, UPDATE
   Supported: timer, 100rel
   Content-Length: 0

   
nta: sent 200 OK for NOTIFY (2)
nua: nua_application_event: entering

Thanks


- Original Message - 
From: Pekka Pessi ppe...@gmail.com
To: Gaurav Srivastva gaurav...@yahoo.com
Cc: sofia-sip-devel@lists.sourceforge.net
Sent: Tuesday, August 10, 2010 10:44 AM
Subject: Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 
200 OK to NOTIFY request


2010/8/10 Gaurav Srivastva gaurav...@yahoo.com:
 Would highly appreciate if someone can tell me if this issue is resolved 
 in
 sofia-sip stack or not.

Are you sure there is no other Via header down the response? ;-o

I've never seen the bug on Linux, but I've added test cases for it in
nta and nua just in case you manage to compile git head on OSX
(patches on any of the problems encountered are welcome).

--Pekka

 On Aug 8, 2010, at 2:49 AM, Gaurav Srivastva wrote:
 The notify request to the subscription is being responded to by Sofia-Sip
 stack with one Via header from the SIP request missing.
 In the NOTIFY, the Via header is,
 Via: SIP/2.0/UDP
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP/2.0/UDP
 172.16.14.209:6015;branch=z9hG4bK86266194643563
 In the 200 OK response, the Via header being sent is,
 Via: SIP/2.0/UDP
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;received=172.16.14.209
 I'm using nua to send the subscribe request.
 handle = nua_handle(appl-nua,
 NULL,
 SIPTAG_FROM(from_header),
 SIPTAG_TO(to_header),
 SIPTAG_ROUTE(route_header),
 SIPTAG_CONTACT(contact_header),
 TAG_END());

 if(handle)
 {
 nua_subscribe(handle,
 SIPTAG_EXPIRES_STR(3600),
 SIPTAG_EVENT_STR(presence),
 SIPTAG_ACCEPT_STR(application/pidf+xml),
 TAG_END());

 }
 The platform is OSX and xcode IDE.
 Can someone tell me what I'm doing wrong or is this a bug in sofia-sip
 stack?
 Thanks
 Gaurav


-- 
Pekka.Pessi mail at nokia.com 



--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[Gaurav Srivastva]

Oh. BTW, this issue is happening in linux as well (the previous captures are 
from centos5 server).

- Original Message - 
From: Pekka Pessi ppe...@gmail.com
To: Gaurav Srivastva gaurav...@yahoo.com
Cc: sofia-sip-devel@lists.sourceforge.net
Sent: Tuesday, August 10, 2010 10:44 AM
Subject: Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 
200 OK to NOTIFY request


2010/8/10 Gaurav Srivastva gaurav...@yahoo.com:
 Would highly appreciate if someone can tell me if this issue is resolved 
 in
 sofia-sip stack or not.

Are you sure there is no other Via header down the response? ;-o

I've never seen the bug on Linux, but I've added test cases for it in
nta and nua just in case you manage to compile git head on OSX
(patches on any of the problems encountered are welcome).

--Pekka

 On Aug 8, 2010, at 2:49 AM, Gaurav Srivastva wrote:
 The notify request to the subscription is being responded to by Sofia-Sip
 stack with one Via header from the SIP request missing.
 In the NOTIFY, the Via header is,
 Via: SIP/2.0/UDP
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP/2.0/UDP
 172.16.14.209:6015;branch=z9hG4bK86266194643563
 In the 200 OK response, the Via header being sent is,
 Via: SIP/2.0/UDP
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;received=172.16.14.209
 I'm using nua to send the subscribe request.
 handle = nua_handle(appl-nua,
 NULL,
 SIPTAG_FROM(from_header),
 SIPTAG_TO(to_header),
 SIPTAG_ROUTE(route_header),
 SIPTAG_CONTACT(contact_header),
 TAG_END());

 if(handle)
 {
 nua_subscribe(handle,
 SIPTAG_EXPIRES_STR(3600),
 SIPTAG_EVENT_STR(presence),
 SIPTAG_ACCEPT_STR(application/pidf+xml),
 TAG_END());

 }
 The platform is OSX and xcode IDE.
 Can someone tell me what I'm doing wrong or is this a bug in sofia-sip
 stack?
 Thanks
 Gaurav


-- 
Pekka.Pessi mail at nokia.com 



--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[Gaurav Srivastva]

The Via headers on Linux are sent correctly if TPORT_LOG is not defined. If I 
define this variable then the problem starts happening.

Odd..


On Aug 10, 2010, at 10:44 AM, Pekka Pessi wrote:

 2010/8/10 Gaurav Srivastva gaurav...@yahoo.com:
 Would highly appreciate if someone can tell me if this issue is resolved in
 sofia-sip stack or not.
 
 Are you sure there is no other Via header down the response? ;-o
 
 I've never seen the bug on Linux, but I've added test cases for it in
 nta and nua just in case you manage to compile git head on OSX
 (patches on any of the problems encountered are welcome).
 
 --Pekka
 
 On Aug 8, 2010, at 2:49 AM, Gaurav Srivastva wrote:
 The notify request to the subscription is being responded to by Sofia-Sip
 stack with one Via header from the SIP request missing.
 In the NOTIFY, the Via header is,
   Via: SIP/2.0/UDP
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP/2.0/UDP
 172.16.14.209:6015;branch=z9hG4bK86266194643563
 In the 200 OK response, the Via header being sent is,
   Via: SIP/2.0/UDP
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;received=172.16.14.209
 I'm using nua to send the subscribe request.
  handle = nua_handle(appl-nua,
  NULL,
  SIPTAG_FROM(from_header),
  SIPTAG_TO(to_header),
  SIPTAG_ROUTE(route_header),
  SIPTAG_CONTACT(contact_header),
  TAG_END());
 
  if(handle)
  {
nua_subscribe(handle,
  SIPTAG_EXPIRES_STR(3600),
  SIPTAG_EVENT_STR(presence),
  SIPTAG_ACCEPT_STR(application/pidf+xml),
  TAG_END());
 
  }
 The platform is OSX and xcode IDE.
 Can someone tell me what I'm doing wrong or is this a bug in sofia-sip
 stack?
 Thanks
 Gaurav
 
 
 -- 
 Pekka.Pessi mail at nokia.com



--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[mikhail.zabaluev]

Hi,

 -Original Message-
 From: ext Gaurav Srivastva [mailto:gaurav...@yahoo.com]
 Sent: Monday, August 09, 2010 5:11 AM
 To: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] sofia-sip not sending correct Via
 headers in 200 OK to NOTIFY request
 
 Looks like my code works fine in linux but is causing problem in OS/X.
 
 Can someone confirm this issue in OS/X?

I have seen something like this on a Linux before.
The problem seemed to be with parsing a Via header that contains multiple 
entries.

Regards,
  Mikhail

 On Aug 8, 2010, at 2:49 AM, Gaurav Srivastva wrote:
 
 
   Hi,
 
   The notify request to the subscription is being responded to by
 Sofia-Sip stack with one Via header from the SIP request missing.
 
   In the NOTIFY, the Via header is,
 
  Via: SIP/2.0/UDP ift-
 uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP
 /2.0/UDP 172.16.14.209:6015;branch=z9hG4bK86266194643563
 
 
   In the 200 OK response, the Via header being sent is,
 
  Via: SIP/2.0/UDP ift-
 uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;rec
 eived=172.16.14.209
 
 
   I'm using nua to send the subscribe request.
 
 handle = nua_handle(appl-nua,
 NULL,
 SIPTAG_FROM(from_header),
 SIPTAG_TO(to_header),
 SIPTAG_ROUTE(route_header),
 SIPTAG_CONTACT(contact_header),
 TAG_END());
 
 
 if(handle)
 {
   nua_subscribe(handle,
 SIPTAG_EXPIRES_STR(3600),
 SIPTAG_EVENT_STR(presence),
 SIPTAG_ACCEPT_STR(application/pidf+xml),
 TAG_END());
 
 
 }
 
   The platform is OSX and xcode IDE.
 
   Can someone tell me what I'm doing wrong or is this a bug in
 sofia-sip stack?
--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[Gaurav Srivastva]

I'm currently using macports for getting sofia-sip on osx (snow leopard). Is 
this issue resolved in the latest git repository? Just want to know if I should 
put some effort in compiling from the git repository since OSX compilation 
doesn't appear straight-forward.



On Aug 9, 2010, at 6:27 AM, mikhail.zabal...@nokia.com 
mikhail.zabal...@nokia.com wrote:

 Hi,
 
 -Original Message-
 From: ext Gaurav Srivastva [mailto:gaurav...@yahoo.com]
 Sent: Monday, August 09, 2010 5:11 AM
 To: sofia-sip-devel@lists.sourceforge.net
 Subject: Re: [Sofia-sip-devel] sofia-sip not sending correct Via
 headers in 200 OK to NOTIFY request
 
 Looks like my code works fine in linux but is causing problem in OS/X.
 
 Can someone confirm this issue in OS/X?
 
 I have seen something like this on a Linux before.
 The problem seemed to be with parsing a Via header that contains multiple 
 entries.
 
 Regards,
  Mikhail
 
 On Aug 8, 2010, at 2:49 AM, Gaurav Srivastva wrote:
 
 
  Hi,
 
  The notify request to the subscription is being responded to by
 Sofia-Sip stack with one Via header from the SIP request missing.
 
  In the NOTIFY, the Via header is,
 
 Via: SIP/2.0/UDP ift-
 uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP
 /2.0/UDP 172.16.14.209:6015;branch=z9hG4bK86266194643563
 
 
  In the 200 OK response, the Via header being sent is,
 
 Via: SIP/2.0/UDP ift-
 uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;rec
 eived=172.16.14.209
 
 
  I'm using nua to send the subscribe request.
 
handle = nua_handle(appl-nua,
NULL,
SIPTAG_FROM(from_header),
SIPTAG_TO(to_header),
SIPTAG_ROUTE(route_header),
SIPTAG_CONTACT(contact_header),
TAG_END());
 
 
if(handle)
{
  nua_subscribe(handle,
SIPTAG_EXPIRES_STR(3600),
SIPTAG_EVENT_STR(presence),
SIPTAG_ACCEPT_STR(application/pidf+xml),
TAG_END());
 
 
}
 
  The platform is OSX and xcode IDE.
 
  Can someone tell me what I'm doing wrong or is this a bug in
 sofia-sip stack?



--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[Gaurav Srivastva]

Hi,

The notify request to the subscription is being responded to by Sofia-Sip stack 
with one Via header from the SIP request missing.

In the NOTIFY, the Via header is,

   Via: SIP/2.0/UDP 
ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP/2.0/UDP
 172.16.14.209:6015;branch=z9hG4bK86266194643563

In the 200 OK response, the Via header being sent is,

   Via: SIP/2.0/UDP 
ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;received=172.16.14.209

I'm using nua to send the subscribe request.

  handle = nua_handle(appl-nua,
  NULL, 
  SIPTAG_FROM(from_header),
  SIPTAG_TO(to_header),
  SIPTAG_ROUTE(route_header),
  SIPTAG_CONTACT(contact_header), 
  TAG_END());
  
  if(handle)
  {
nua_subscribe(handle, 
  SIPTAG_EXPIRES_STR(3600),
  SIPTAG_EVENT_STR(presence),
  SIPTAG_ACCEPT_STR(application/pidf+xml),
  TAG_END());

  }

The platform is OSX and xcode IDE.

Can someone tell me what I'm doing wrong or is this a bug in sofia-sip stack?

Thanks
Gaurav--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] sofia-sip not sending correct Via headers in 200 OK to NOTIFY request

[Gaurav Srivastva]

Looks like my code works fine in linux but is causing problem in OS/X.

Can someone confirm this issue in OS/X?

Thanks



On Aug 8, 2010, at 2:49 AM, Gaurav Srivastva wrote:

 Hi,
 
 The notify request to the subscription is being responded to by Sofia-Sip 
 stack with one Via header from the SIP request missing.
 
 In the NOTIFY, the Via header is,
 
Via: SIP/2.0/UDP 
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1,SIP/2.0/UDP
  172.16.14.209:6015;branch=z9hG4bK86266194643563
 
 In the 200 OK response, the Via header being sent is,
 
Via: SIP/2.0/UDP 
 ift-uca.mitel.com:5060;branch=z9hG4bK693c3fbd3b6fa114ad984c7a522a1964.1;received=172.16.14.209
 
 I'm using nua to send the subscribe request.
 
   handle = nua_handle(appl-nua,
   NULL, 
   SIPTAG_FROM(from_header),
   SIPTAG_TO(to_header),
   SIPTAG_ROUTE(route_header),
   SIPTAG_CONTACT(contact_header), 
   TAG_END());
   
   if(handle)
   {
 nua_subscribe(handle, 
   SIPTAG_EXPIRES_STR(3600),
   SIPTAG_EVENT_STR(presence),
   SIPTAG_ACCEPT_STR(application/pidf+xml),
   TAG_END());
 
   }
 
 The platform is OSX and xcode IDE.
 
 Can someone tell me what I'm doing wrong or is this a bug in sofia-sip stack?
 
 Thanks
 Gaurav
 --
 This SF.net email is sponsored by 
 
 Make an app they can't live without
 Enter the BlackBerry Developer Challenge
 http://p.sf.net/sfu/RIM-dev2dev 
 ___
 Sofia-sip-devel mailing list
 Sofia-sip-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass

[SourceForge.net]

Bugs item #3034730, was opened at 2010-07-26 18:02
Message generated for change (Comment added) made by ppessi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3034730group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build system
Group: None
Status: Pending
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Pacho Ramos (pacho2)
Assigned to: Nobody/Anonymous (nobody)
Summary: torture_url test fail to pass

Initial Comment:
This has been noticed downstream:
http://bugs.gentoo.org/show_bug.cgi?id=328733#c2

PASS: run_test_sdp
==
All 2 tests passed
==
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
Making check in url
make[2]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-am
make[3]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  torture_url
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. 
-I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt 
-I./../su -I../su   -Wall -O2 -march=native -pipe -fomit-frame-pointer 
-ggdb -MT torture_url.o -MD -MP -MF .deps/torture_url.Tpo -c -o torture_url.o 
torture_url.c; \
then mv -f .deps/torture_url.Tpo .deps/torture_url.Po; else rm -f 
.deps/torture_url.Tpo; exit 1; fi
/bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 
-march=native -pipe -fomit-frame-pointer -ggdb  -Wl,-O1 -Wl,--as-needed -o 
torture_url  torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la 
../su/libsu.la -lssl -lcrypto -lrt -lpthread 
i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb 
-Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o  ./.libs/liburl.a 
../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto 
-lrt -lpthread  
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-TESTS
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
torture_url.c:279: torture_url test_sip() FAILED: 
url_query_as_header_string(home, url-url_headers) != \n\nCANNED MSG or NULL 
!= 

CANNED MSG
FAIL: torture_url
===
1 of 1 tests failed
===
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[2]: *** [check] Error 2
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua'
make: *** [check-recursive] Error 1

And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6

Thanks a lot for solving this

--

Comment By: Pekka Pessi (ppessi)
Date: 2010-08-04 17:47

Message:
Which compiler is used there? Can you get gcc -v and cat /proc/cpuinfo from
those who are bitten by this bug?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3034730group_id=143636

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3035859 ] Sofia Stack not rejecting Invite with out CallID and To TAG

[SourceForge.net]

Bugs item #3035859, was opened at 2010-07-28 15:57
Message generated for change (Tracker Item Submitted) made by vikasverin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3035859group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vikas Bhat (vikasverin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sofia Stack not rejecting Invite with out CallID and To TAG 

Initial Comment:
Sofia Stack is allowing the call with out CallID .
Also Call is allowed without the TO TAG.
Stack should reject the call without any one from the following fields :   
CallID ,or TO Tag or To or BranchID
but call is allowed in the above scenerio.
can you guide me if i need to do any change in stack side or use any particular 
version of Sofia.

Thanks
Vikas Bhat

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3035859group_id=143636

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3034730 ] torture_url test fail to pass

[SourceForge.net]

Bugs item #3034730, was opened at 2010-07-26 17:02
Message generated for change (Tracker Item Submitted) made by pacho2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3034730group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: build system
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pacho Ramos (pacho2)
Assigned to: Nobody/Anonymous (nobody)
Summary: torture_url test fail to pass

Initial Comment:
This has been noticed downstream:
http://bugs.gentoo.org/show_bug.cgi?id=328733#c2

PASS: run_test_sdp
==
All 2 tests passed
==
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/sdp'
Making check in url
make[2]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-am
make[3]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  torture_url
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
if i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. 
-I../../libsofia-sip-ua/su/sofia-sip -I./../bnf -I../bnf -I./../ipt -I../ipt 
-I./../su -I../su   -Wall -O2 -march=native -pipe -fomit-frame-pointer 
-ggdb -MT torture_url.o -MD -MP -MF .deps/torture_url.Tpo -c -o torture_url.o 
torture_url.c; \
then mv -f .deps/torture_url.Tpo .deps/torture_url.Po; else rm -f 
.deps/torture_url.Tpo; exit 1; fi
/bin/sh ../../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -Wall -O2 
-march=native -pipe -fomit-frame-pointer -ggdb  -Wl,-O1 -Wl,--as-needed -o 
torture_url  torture_url.o liburl.la ../bnf/libbnf.la ../ipt/libipt.la 
../su/libsu.la -lssl -lcrypto -lrt -lpthread 
i686-pc-linux-gnu-gcc -Wall -O2 -march=native -pipe -fomit-frame-pointer -ggdb 
-Wl,-O1 -Wl,--as-needed -o torture_url torture_url.o  ./.libs/liburl.a 
../bnf/.libs/libbnf.a ../ipt/.libs/libipt.a ../su/.libs/libsu.a -lssl -lcrypto 
-lrt -lpthread  
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make  check-TESTS
make[4]: Entering directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
torture_url.c:279: torture_url test_sip() FAILED: 
url_query_as_header_string(home, url-url_headers) != \n\nCANNED MSG or NULL 
!= 

CANNED MSG
FAIL: torture_url
===
1 of 1 tests failed
===
make[4]: *** [check-TESTS] Error 1
make[4]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[3]: *** [check-am] Error 2
make[3]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[2]: *** [check] Error 2
make[2]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua/url'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/var/tmp/portage/net-libs/sofia-sip-1.12.10/work/sofia-sip-1.12.10/libsofia-sip-ua'
make: *** [check-recursive] Error 1

And there is a possible fix in http://bugs.gentoo.org/show_bug.cgi?id=328733#c6

Thanks a lot for solving this

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3034730group_id=143636

--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share 
of $1 Million in cash or HP Products. Visit us here for more details:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails

[SourceForge.net]

Bugs item #2412241, was opened at 2008-12-09 18:06
Message generated for change (Comment added) made by gehrehmee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2412241group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pekka Pessi (ppessi)
Assigned to: Pekka Pessi (ppessi)
Summary: Registration to Ekiga.net fails

Initial Comment:
The Ekiga.net checks during registration that both the Via and Contact headers 
contain a public IP address. The registation fails with 606 if the Via header 
contains a NATted address from the private address space.

--

Comment By: Jeremy Nickurak (gehrehmee)
Date: 2010-07-19 15:33

Message:
Affecting Ubuntu via https://bugs.launchpad.net/ekiga/+bug/294994 , debian
via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535796 , both via
telepathy-sofiasip on https://bugs.freedesktop.org/show_bug.cgi?id=19328

--

Comment By: Johan Brannlund (jbrnd)
Date: 2010-01-21 17:34

Message:
I'm not 100% sure I did everything correctly, but using sofia-sip trunk
didn't change anything for me.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-11-13 16:26

Message:
What do you know, it works for me with the sofia-sip build we use in Maemo
5.

Can somebody else confirm if it works with sofia-sip trunk?

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-10-15 11:47

Message:
 So, if the problem is with ekiga.net, has anyone contacted them about it
yet?

Sort of; last word I heard from them is, they need this restriction so
that their own client keeps working. I still think they shouldn't impose a
restriction on the address in Via, and sofia-sip should now re-register
with a discovered mapped address in Contact. I didn't press this last
comment to them yet, though.

--

Comment By: Murray Cumming (murrayc)
Date: 2009-10-13 05:50

Message:
So, if the problem is with ekiga.net, has anyone contacted them about it
yet?

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-06-08 13:54

Message:
I reverse my stance from the earlier comments The modification of transport
address in Via may cause interoperability problems with proxies that
implement support for RFC 3581 and rely on the specified behavior for
NAT-aware policies.

The restriction imposed by the proxy is arbitrary. It does not follow any
specification or best practice published by IETF that I'm aware of. The
answer is, fix the proxy.

--

Comment By: Andre Klapper (riot69)
Date: 2009-04-09 09:51

Message:
Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-03-03 18:49

Message:
It shouldn't be an interop problem to put the public transport address in
the client's Via. When the binding breaks, the proxy should signal it with
rport and received which will be different from the address in Via.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2008-12-10 13:17

Message:
The UA application must take care of the contact address by:
-Using some kind of STUN mechanism
- Learning from the REGISTER response ( checking the Via parameters ) and
reusing a new REGISTER

Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with
606 Not Acceptable.

--

Comment By: Inca Rose (incarose)
Date: 2008-12-09 19:48

Message:
Why do you think this is a sofia-sip problem ?
There is nothing wrong whit that.
Ekiga SIP server will end up sending the response to the udp-src address
ignoring the Via host address.

The UA application must take care of the contact address by:
-Using some kind of STUN mechanism
- Learning from the REGISTER response ( checking the Via parameters ) and
reusing a new REGISTER
- or not taking care at all and failing to get incoming calls.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2412241group_id=143636

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit 

[Sofia-sip-devel] [ sofia-sip-Bugs-2412241 ] Registration to Ekiga.net fails

[SourceForge.net]

Bugs item #2412241, was opened at 2008-12-09 18:06
Message generated for change (Comment added) made by gehrehmee
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=2412241group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pekka Pessi (ppessi)
Assigned to: Pekka Pessi (ppessi)
Summary: Registration to Ekiga.net fails

Initial Comment:
The Ekiga.net checks during registration that both the Via and Contact headers 
contain a public IP address. The registation fails with 606 if the Via header 
contains a NATted address from the private address space.

--

Comment By: Jeremy Nickurak (gehrehmee)
Date: 2010-07-19 15:39

Message:
Reported against ekiga's bug tracker at:
https://bugzilla.gnome.org/show_bug.cgi?id=624751

--

Comment By: Jeremy Nickurak (gehrehmee)
Date: 2010-07-19 15:33

Message:
Affecting Ubuntu via https://bugs.launchpad.net/ekiga/+bug/294994 , debian
via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535796 , both via
telepathy-sofiasip on https://bugs.freedesktop.org/show_bug.cgi?id=19328

--

Comment By: Johan Brannlund (jbrnd)
Date: 2010-01-21 17:34

Message:
I'm not 100% sure I did everything correctly, but using sofia-sip trunk
didn't change anything for me.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-11-13 16:26

Message:
What do you know, it works for me with the sofia-sip build we use in Maemo
5.

Can somebody else confirm if it works with sofia-sip trunk?

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-10-15 11:47

Message:
 So, if the problem is with ekiga.net, has anyone contacted them about it
yet?

Sort of; last word I heard from them is, they need this restriction so
that their own client keeps working. I still think they shouldn't impose a
restriction on the address in Via, and sofia-sip should now re-register
with a discovered mapped address in Contact. I didn't press this last
comment to them yet, though.

--

Comment By: Murray Cumming (murrayc)
Date: 2009-10-13 05:50

Message:
So, if the problem is with ekiga.net, has anyone contacted them about it
yet?

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-06-08 13:54

Message:
I reverse my stance from the earlier comments The modification of transport
address in Via may cause interoperability problems with proxies that
implement support for RFC 3581 and rely on the specified behavior for
NAT-aware policies.

The restriction imposed by the proxy is arbitrary. It does not follow any
specification or best practice published by IETF that I'm aware of. The
answer is, fix the proxy.

--

Comment By: Andre Klapper (riot69)
Date: 2009-04-09 09:51

Message:
Maemo downstream ticket: https://bugs.maemo.org/show_bug.cgi?id=4259

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2009-03-03 18:49

Message:
It shouldn't be an interop problem to put the public transport address in
the client's Via. When the binding breaks, the proxy should signal it with
rport and received which will be different from the address in Via.

--

Comment By: Mikhail Zabaluev (mzabaluev)
Date: 2008-12-10 13:17

Message:
The UA application must take care of the contact address by:
-Using some kind of STUN mechanism
- Learning from the REGISTER response ( checking the Via parameters ) and
reusing a new REGISTER

Sure, we do the latter, but the ekiga.net proxy rejects this REGISTER with
606 Not Acceptable.

--

Comment By: Inca Rose (incarose)
Date: 2008-12-09 19:48

Message:
Why do you think this is a sofia-sip problem ?
There is nothing wrong whit that.
Ekiga SIP server will end up sending the response to the udp-src address
ignoring the Via host address.

The UA application must take care of the contact address by:
-Using some kind of STUN mechanism
- Learning from the REGISTER response ( checking the Via parameters ) and
reusing a new REGISTER
- or not taking care at all and failing to get incoming calls.

--

You can respond by visiting: 

[Sofia-sip-devel] [ sofia-sip-Bugs-3027352 ] Unable nua_destroy(), since nua_r_shutdown never arrives

[SourceForge.net]

Bugs item #3027352, was opened at 2010-07-09 13:55
Message generated for change (Tracker Item Submitted) made by scorpfa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3027352group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Scorp (scorpfa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable nua_destroy(), since nua_r_shutdown never arrives

Initial Comment:
Following Code for shutting down UA and Root is not working, because  
nua_r_shutdown event never comes through the event handler.

nua_shutdown(m_nua);

// -- Here: endless waiting for nua_r_shutdown

su_root_break(getRoot());
nua_destroy(m_nua); // -- This would fail, since shutdown was not completed

Cheers

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3027352group_id=143636

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3027352 ] Unable nua_destroy(), since nua_r_shutdown never arrives

[SourceForge.net]

Bugs item #3027352, was opened at 2010-07-09 13:55
Message generated for change (Settings changed) made by scorpfa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3027352group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Scorp (scorpfa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable nua_destroy(), since nua_r_shutdown never arrives

Initial Comment:
Following Code for shutting down UA and Root is not working, because  
nua_r_shutdown event never comes through the event handler.

nua_shutdown(m_nua);

// -- Here: endless waiting for nua_r_shutdown

su_root_break(getRoot());
nua_destroy(m_nua); // -- This would fail, since shutdown was not completed

Cheers

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3027352group_id=143636

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Bugs-3000830 ] sofia sip client with openimscore

[SourceForge.net]

Bugs item #3000830, was opened at 2010-05-13 01:32
Message generated for change (Tracker Item Submitted) made by wepawetmose
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3000830group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: wepawetmose (wepawetmose)
Assigned to: Nobody/Anonymous (nobody)
Summary: sofia sip client with openimscore

Initial Comment:
Hi, im using sofia sip client with openimscore and i need to get it 
communicating each other.

...surely Expires is a nice to have header :-)
I've added it to sofsip_cli and now both Alice and Bob appear as REGISTERED in 
FHoSS web interface

well, THIS is exactly what i wanna do but dont know how!

if Starting the service:
sofsip_cli --media-impl=dummy --registrar=sip:open-ims.test 
--proxy=sip:pcscf.open-ims.test:4060 

I get:
su_source_port_create() returns 0x90a4234
** (sofsip_cli:4350): DEBUG: ssc_media_class_init:124
** (sofsip_cli:4350): DEBUG: ssc_media_init:169
** Message: Selecting media implementation: dummy
sofsip UA: unknown event 'nua_r_set_params' (23): 200 OK
   ::tag_null: 0
NOTE: destroying handle (nil).
sofsip UA: nua_r_getparams: 200 OK
   sip::from: sip:172.16.6.159
   sip::from_str: sip:172.16.6.159
   nua::retry_count: 3
   nua::max_subscriptions: 20
   nua::media_enable: true
   nua::enableInvite: true
   nua::autoAlert: true
   nua::early_media: false
   nua::only183_100rel: false
   nua::autoAnswer: false
   nua::autoACK: true
   nua::invite_timer: 120
   nua::session_timer: 0
   nua::min_se: 120
   nua::session_refresher: 0
   nua::update_refresh: false
   nua::enableMessage: true
   nua::enableMessenger: false
   nua::callee_caps: false
   nua::media_features: false
   nua::service_route_enable: true
   nua::path_enable: true
   nua::refer_expires: 300
   nua::refer_with_id: true
   nua::substate: 2
   nua::substate: 3600
   sip::supported: timer, 100rel
   sip::supported_str: timer, 100rel
   sip::allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, 
NOTIFY, REFER, UPDATE
   sip::allow_str: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, 
SUBSCRIBE, NOTIFY, REFER, UPDATE
   nua::appl_method: INVITE, REGISTER, PUBLISH, SUBSCRIBE
   sip::user_agent: sofia-sip/1.12.10
   sip::user_agent_str: sofia-sip/1.12.10
   nua::user_agent: sofia-sip/1.12.10
   nua::registrar: sip:open-ims.test
   nua::keepalive: 12
   nua::outbound: natify
   nta::contact: sip:172.16.6.159
   nta::udp_mtu: 1300
   nta::max_proceeding: 4294967295
   nta::sip_t1: 500
   nta::sip_t2: 4000
   nta::sip_t4: 5000
   nta::sip_t1x64: 32000
   nta::debug_drop_prob: 0
   nta::default_proxy: sip:pcscf.open-ims.test:4060
   nta::aliases: NONE
   nta::sipflags: 2
   soa::caps_sdp: v=0
o=- 7732089869805783786 4683031078712322020 IN IP4 172.16.6.159
s=-
c=IN IP4 172.16.6.159
t=0 0
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
   soa::caps_sdp_str: v=0
o=- 7732089869805783786 4683031078712322020 IN IP4 172.16.6.159
s=-
c=IN IP4 172.16.6.159
t=0 0
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000

   soa::user_sdp: v=0
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
   soa::user_sdp_str: v=0
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000

   soa::local_sdp_str: null
   soa::af: 3
   soa::srtp_enable: false
   soa::srtp_confidentiality: false
   soa::srtp_integrity: false
   ::tag_null: 0

Starting sofsip-cli in interactive mode. Issue 'h' to get list of available 
commands.
sofsip

witch is good, so far.

then: 
addr sip:b...@open-ims.test
sofsip UA: unknown event 'nua_r_set_params' (23): 200 OK
   ::tag_null: 0
NOTE: destroying handle (nil).
sofsip 


not so good, but works!

BUT after:
sofsip r
UA: REGISTER sip:b...@open-ims.test - updating existing registration
sofsip UA: REGISTER: 401 Unauthorized - Challenging the UE
Server auth: Digest realm=open-ims.test, 
nonce=97FmRP9GLEaTRubVfl5/CDSc+jk9dQAAi7fVOC81s9I=, algorithm=AKAv1-MD5, 
qop=auth,auth-int
Please authenticate 'Digest' with the 'k' command (e.g. 'k password', or 'k 
[method:realm:username:]password')
sofsip 

I get an error in openimscore:
ERR: P-CSCF:cscf_get_authorization: Message does not contain Authorization 
header.


Can anyone help me?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756076aid=3000830group_id=143636

--

___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] Sofia-SIP sorting of SRV records defeats DNS server round-robin SIP traffic distribution

[Jim Thomas]

Hello,

I am using Sofia-SIP 1.12.10 and it works great.  Thank you
for your open source contribution.

I use an ITSP where, until recently, a DNS lookup by Sofia-SIP
would obtain a single SRV record.  Outbound SIP calls work as
expected every time.

The ITSP now wants to distribute the SIP traffic across three
destinations (three cities), so the same DNS lookup by Sofia-SIP
obtains three SRV records.

The DNS server is provisioned to rotate the SRV records
round-robin, so the first choice will alternate among the three
destinations.  I can see in a packet trace that the SRV record
sequence is in fact alternating across DNS lookups.  (These are
the external DNS lookups after the Sofia-SIP DNS cache expires).
The problem is that even though the DNS response presents the
SRV records in varying order, Sofia-SIP always selects the same
particular SRV record, so outbound calls always go to a single
destination and are not distributed.

I reviewed the Sofia-SIP source, and think I see what is
happening.

Sofia-SIP sorts the SRV records on priority, weight, srv_target,
and srv_port:

  sofia-resolv/sres_record.h
    /** Service location record (@RFC2782). */
    typedef struct sres_srv_record
    {
  sres_common_t  srv_record[1];  /** Common part of DNS records. */
  uint16_t   srv_priority;   /** Priority */
  uint16_t   srv_weight; /** Weight */
  uint16_t   srv_port;   /** Service port on the target host. */
  uint16_t   srv_pad;
  char  *srv_target; /** Domain name of the target host. */
    } sres_srv_record_t;

  sres.c

    sres_record_compare(sres_record_t const *aa, sres_record_t const *bb)
    {
  snip
  case sres_type_srv:
    {
  sres_srv_record_t const *A = aa-sr_srv, *B = bb-sr_srv;
  D = A-srv_priority - B-srv_priority; if (D) return D;
  /* Record with larger weight first */
  D = B-srv_weight - A-srv_weight; if (D) return D;
  D = strcmp(A-srv_target, B-srv_target); if (D) return D;
  return A-srv_port - B-srv_port;
    }
  snip
    }

If the priority and weight are identical for all three SRV records,
as they are with my ITSP, then the alpha sort of the srv_target name
determines the SRV record sort sequence.

The result is that Sofia-SIP loses the SRV record sequence intended
by the round-robin ordering by the DNS server, and the SRV record
selected by Sofia-SIP is always the record that just happens to have
the target name with the lowest alpha sort key.

It seems to me that the correct sort would be by priority and weight
only, and where those are identical for adjacent records, the original
SRV record sequence would be preserved so the first choice intended
by the DNS server round-robin ordering would be used by Sofia-SIP
to determine where to send the SIP for the outbound call.

Thanks.

Jim



  --
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

[Sofia-sip-devel] [ sofia-sip-Patches-2966302 ] Allow : character in authentication realms

[SourceForge.net]

Patches item #2966302, was opened at 2010-03-09 12:26
Message generated for change (Tracker Item Submitted) made by darrenb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756078aid=2966302group_id=143636

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Darren Bane (darrenb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow : character in authentication realms

Initial Comment:
According to the SIP RFC, they should be allowed (quoted-string). And we've 
seen this done by an ITSP.
-- 
Darren Bane, Emutex Ltd.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=756078aid=2966302group_id=143636

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel

Re: [Sofia-sip-devel] SOFIA SIP EXAMPLE

[Aleksander Morgado]

 I'd like to run an example (sip client) using SOFIA SIP Stack on Windows
 Vista. I already download the SOFIA SIP. Do I need to compile all the code ?
 Where can I find some example in order to see SOFIA SIP working?


SofSipCli may help: http://wiki.opensource.nokia.com/projects/SofSipCli

Cheers,
-Aleksander
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev___
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel